Xin chào các độc giả của Habr. Với bài viết này, chúng tôi mở ra một loạt bài nói về hệ thống siêu hội tụ AERODISK vAIR mà chúng tôi đã phát triển. Ban đầu, chúng tôi muốn kể mọi chuyện trong bài viết đầu tiên, nhưng hệ thống khá phức tạp nên chúng tôi sẽ ăn thịt con voi theo từng phần.
Hãy bắt đầu câu chuyện với lịch sử hình thành hệ thống, đi sâu vào hệ thống tệp ARDFS, nền tảng của vAIR, đồng thời nói một chút về vị trí của giải pháp này trên thị trường Nga.
Trong các bài viết sau, chúng tôi sẽ nói chi tiết hơn về các thành phần kiến trúc khác nhau (cụm, bộ ảo hóa, bộ cân bằng tải, hệ thống giám sát, v.v.), quy trình cấu hình, nêu vấn đề cấp phép, hiển thị riêng các thử nghiệm sự cố và tất nhiên là viết về thử nghiệm tải và định cỡ. Chúng tôi cũng sẽ dành một bài viết riêng cho phiên bản cộng đồng của vAIR.
Aerodisk có phải là câu chuyện về hệ thống lưu trữ? Hoặc tại sao chúng ta lại bắt đầu thực hiện siêu hội tụ ngay từ đầu?
Ban đầu, ý tưởng tạo ra siêu hội tụ của riêng chúng tôi đến với chúng tôi vào khoảng năm 2010. Vào thời điểm đó, không có Aerodisk cũng như các giải pháp tương tự (hệ thống siêu hội tụ đóng hộp thương mại) trên thị trường. Nhiệm vụ của chúng tôi là như sau: từ một tập hợp các máy chủ có đĩa cục bộ, được hợp nhất bằng một kết nối thông qua giao thức Ethernet, cần phải tạo một bộ lưu trữ mở rộng và khởi chạy các máy ảo và mạng phần mềm ở đó. Tất cả điều này phải được thực hiện mà không cần hệ thống lưu trữ (vì đơn giản là không có tiền cho hệ thống lưu trữ và phần cứng của nó, và chúng tôi vẫn chưa phát minh ra hệ thống lưu trữ của riêng mình).
Chúng tôi đã thử nhiều giải pháp nguồn mở và cuối cùng đã giải quyết được vấn đề này, nhưng giải pháp này rất phức tạp và khó lặp lại. Ngoài ra, giải pháp này nằm trong danh mục “Có hiệu quả không? Đừng chạm vào! Vì vậy, sau khi giải quyết được vấn đề đó, chúng tôi không phát triển thêm ý tưởng biến kết quả công việc của mình thành một sản phẩm hoàn chỉnh.
Sau sự cố đó, chúng tôi đã từ bỏ ý tưởng này, nhưng chúng tôi vẫn có cảm giác rằng vấn đề này hoàn toàn có thể giải quyết được và lợi ích của giải pháp đó còn rõ ràng hơn. Sau đó, các sản phẩm HCI được tung ra thị trường của các công ty nước ngoài chỉ khẳng định cảm giác này.
Vì vậy, vào giữa năm 2016, chúng tôi đã quay lại nhiệm vụ này như một phần của việc tạo ra một sản phẩm hoàn chỉnh. Vào thời điểm đó, chúng tôi chưa có bất kỳ mối quan hệ nào với các nhà đầu tư nên chúng tôi phải tự mua một gian hàng phát triển với số tiền không lớn lắm. Sau khi thu thập các máy chủ đã qua sử dụng và công tắc trên Avito, chúng tôi bắt tay vào công việc.
Nhiệm vụ ban đầu chính là tạo ra hệ thống tệp của riêng chúng tôi, mặc dù đơn giản nhưng của riêng chúng tôi, có thể phân phối dữ liệu tự động và đồng đều dưới dạng khối ảo trên số nút cụm thứ n, được kết nối bằng một kết nối qua Ethernet. Đồng thời, FS phải mở rộng quy mô tốt, dễ dàng và độc lập với các hệ thống lân cận, tức là. bị xa lánh khỏi vAIR dưới hình thức “chỉ là một cơ sở lưu trữ”.
Khái niệm vAIR đầu tiên
Chúng tôi đã cố tình từ bỏ việc sử dụng các giải pháp nguồn mở làm sẵn để tổ chức lưu trữ kéo dài (ceph, gluster, lustre và những thứ tương tự) để ủng hộ sự phát triển của chính chúng tôi, vì chúng tôi đã có nhiều kinh nghiệm dự án với chúng. Tất nhiên, bản thân những giải pháp này đều rất xuất sắc và trước khi làm việc trên Aerodisk, chúng tôi đã triển khai nhiều dự án tích hợp với chúng. Nhưng việc thực hiện một nhiệm vụ cụ thể cho một khách hàng là một chuyện, đào tạo nhân viên và có lẽ là mua sự hỗ trợ của một nhà cung cấp lớn, và một việc khác là tạo ra một sản phẩm dễ dàng nhân rộng sẽ được sử dụng cho nhiều nhiệm vụ khác nhau, mà chúng tôi, với tư cách là một nhà cung cấp, thậm chí có thể biết về bản thân chúng tôi thì chúng tôi sẽ không. Với mục đích thứ hai, các sản phẩm nguồn mở hiện có không phù hợp với chúng tôi, vì vậy chúng tôi quyết định tự tạo một hệ thống tệp phân tán.
Hai năm sau, một số nhà phát triển (những người đã kết hợp công việc trên vAIR với công việc trên hệ thống lưu trữ Engine cổ điển) đã đạt được một số kết quả nhất định.
Đến năm 2018, chúng tôi đã viết một hệ thống tệp đơn giản và bổ sung phần cứng cần thiết cho nó. Hệ thống kết hợp các đĩa vật lý (cục bộ) từ các máy chủ khác nhau thành một nhóm phẳng thông qua kết nối nội bộ và “cắt” chúng thành các khối ảo, sau đó tạo khối các thiết bị có mức độ chịu lỗi khác nhau từ các khối ảo, trên đó các khối ảo được tạo và được thực thi bằng cách sử dụng xe ảo hóa KVM.
Chúng tôi không bận tâm quá nhiều đến tên của hệ thống tệp và gọi ngắn gọn là ARDFS (đoán xem nó là viết tắt của từ gì))
Nguyên mẫu này trông đẹp (tất nhiên là không trực quan, chưa có thiết kế trực quan) và cho kết quả tốt về hiệu suất và khả năng mở rộng. Sau kết quả thực sự đầu tiên, chúng tôi bắt đầu thực hiện dự án này, tổ chức một môi trường phát triển chính thức và một nhóm riêng biệt chỉ xử lý vAIR.
Vào thời điểm đó, kiến trúc chung của giải pháp đã hoàn thiện và chưa trải qua những thay đổi lớn.
Đi sâu vào hệ thống tệp ARDFS
ARDFS là nền tảng của vAIR, cung cấp khả năng lưu trữ dữ liệu phân tán, có khả năng chịu lỗi trên toàn bộ cụm. Một trong những tính năng đặc biệt (nhưng không phải duy nhất) của ARDFS là nó không sử dụng bất kỳ máy chủ chuyên dụng bổ sung nào để quản lý và siêu dữ liệu. Điều này ban đầu được hình thành để đơn giản hóa cấu hình của giải pháp và độ tin cậy của nó.
Cấu trúc lưu trữ
Trong tất cả các nút của cụm, ARDFS tổ chức một nhóm logic từ tất cả không gian đĩa có sẵn. Điều quan trọng là phải hiểu rằng nhóm chưa phải là dữ liệu hoặc không gian được định dạng mà chỉ đơn giản là đánh dấu, tức là. Bất kỳ nút nào đã cài đặt vAIR, khi được thêm vào cụm, sẽ tự động được thêm vào nhóm ARDFS được chia sẻ và tài nguyên ổ đĩa sẽ tự động được chia sẻ trên toàn bộ cụm (và có sẵn để lưu trữ dữ liệu trong tương lai). Cách tiếp cận này cho phép bạn thêm và xóa các nút một cách nhanh chóng mà không có bất kỳ tác động nghiêm trọng nào đến hệ thống đang chạy. Những thứ kia. hệ thống rất dễ dàng mở rộng quy mô “theo khối”, thêm hoặc xóa các nút trong cụm nếu cần.
Các đĩa ảo (đối tượng lưu trữ cho máy ảo) được thêm vào bên trên nhóm ARDFS, được xây dựng từ các khối ảo có kích thước 4 megabyte. Đĩa ảo lưu trữ dữ liệu trực tiếp. Sơ đồ chịu lỗi cũng được đặt ở cấp độ đĩa ảo.
Như bạn có thể đã đoán, đối với khả năng chịu lỗi của hệ thống con đĩa, chúng tôi không sử dụng khái niệm RAID (Mảng dự phòng của các đĩa độc lập) mà sử dụng RAIN (Mảng dự phòng của các nút độc lập). Những thứ kia. Khả năng chịu lỗi được đo lường, tự động hóa và quản lý dựa trên các nút chứ không phải trên đĩa. Tất nhiên, đĩa cũng là một đối tượng lưu trữ, giống như mọi thứ khác, chúng được giám sát, bạn có thể thực hiện tất cả các thao tác tiêu chuẩn với chúng, bao gồm cả việc lắp ráp một RAID phần cứng cục bộ, nhưng cụm hoạt động cụ thể trên các nút.
Trong trường hợp bạn thực sự muốn RAID (ví dụ: một kịch bản hỗ trợ nhiều lỗi trên các cụm nhỏ), không có gì ngăn cản bạn sử dụng bộ điều khiển RAID cục bộ cũng như xây dựng bộ lưu trữ mở rộng và kiến trúc RAIN ở trên cùng. Kịch bản này khá trực quan và được chúng tôi hỗ trợ, vì vậy chúng tôi sẽ nói về nó trong một bài viết về các kịch bản điển hình khi sử dụng vAIR.
Sơ đồ dung sai lỗi lưu trữ
Có thể có hai sơ đồ dung sai cho ổ đĩa ảo trong vAIR:
1) Hệ số sao chép hoặc đơn giản là sao chép - phương pháp chịu lỗi này đơn giản như một cây gậy và một sợi dây. Sao chép đồng bộ được thực hiện giữa các nút với hệ số 2 (2 bản sao trên mỗi cụm) hoặc 3 (tương ứng 3 bản sao). RF-2 cho phép đĩa ảo chịu được sự cố của 3 nút trong cụm, nhưng “ăn” một nửa dung lượng hữu ích, còn RF-2 sẽ chịu được sự cố của 2 nút trong cụm, nhưng dự trữ 3/1 dung lượng khối lượng hữu ích cho nhu cầu của nó. Sơ đồ này rất giống với RAID-2, nghĩa là một đĩa ảo được định cấu hình trong RF-XNUMX có khả năng chống lại sự hỏng hóc của bất kỳ nút nào trong cụm. Trong trường hợp này, mọi thứ sẽ ổn với dữ liệu và thậm chí I/O sẽ không dừng lại. Khi nút bị hỏng quay trở lại hoạt động, quá trình khôi phục/đồng bộ hóa dữ liệu tự động sẽ bắt đầu.
Dưới đây là ví dụ về việc phân phối dữ liệu RF-2 và RF-3 ở chế độ bình thường và trong tình huống lỗi.
Chúng tôi có một máy ảo có dung lượng 8 MB dữ liệu duy nhất (hữu ích), chạy trên 4 nút vAIR. Rõ ràng là trên thực tế khó có thể có khối lượng nhỏ như vậy, nhưng đối với một sơ đồ phản ánh logic hoạt động của ARDFS thì ví dụ này là dễ hiểu nhất. AB là các khối ảo 4 MB chứa dữ liệu máy ảo duy nhất. RF-2 tạo ra hai bản sao tương ứng của các khối A1+A2 và B1+B2 này. Các khối này được “bố trí” xuyên suốt các nút, tránh sự giao nhau của cùng một dữ liệu trên cùng một nút, tức là bản sao A1 sẽ không nằm trên cùng một nút với bản sao A2. Tương tự với B1 và B2.
Nếu một trong các nút bị lỗi (ví dụ: nút số 3, chứa bản sao của B1), bản sao này sẽ tự động được kích hoạt trên nút không có bản sao của bản sao của nó (tức là bản sao của B2).
Do đó, đĩa ảo (và VM tương ứng) có thể dễ dàng tồn tại khi một nút trong sơ đồ RF-2 bị lỗi.
Sơ đồ sao chép tuy đơn giản và đáng tin cậy nhưng lại gặp phải vấn đề tương tự như RAID1 - không đủ dung lượng sử dụng.
2) Mã hóa xóa hoặc mã hóa xóa (còn được gọi là “mã hóa dự phòng”, “mã hóa xóa” hoặc “mã dự phòng”) tồn tại để giải quyết vấn đề trên. EC là một sơ đồ dự phòng cung cấp tính sẵn sàng dữ liệu cao với chi phí không gian đĩa thấp hơn so với sao chép. Nguyên lý hoạt động của cơ chế này tương tự như RAID 5, 6, 6P.
Khi mã hóa, quy trình EC chia một khối ảo (4 MB theo mặc định) thành nhiều "khối dữ liệu" nhỏ hơn tùy thuộc vào sơ đồ EC (ví dụ: sơ đồ 2+1 chia mỗi khối 4 MB thành 2 khối 2 MB). Tiếp theo, quá trình này tạo ra “các khối chẵn lẻ” cho các “khối dữ liệu” không lớn hơn một trong các phần được chia trước đó. Khi giải mã, EC tạo ra các đoạn bị thiếu bằng cách đọc dữ liệu “còn sót lại” trên toàn bộ cụm.
Ví dụ: một đĩa ảo có sơ đồ 2 + 1 EC, được triển khai trên 4 nút cụm, sẽ dễ dàng chịu được sự cố của một nút trong cụm giống như RF-2. Trong trường hợp này, chi phí chung sẽ thấp hơn, cụ thể hệ số công suất hữu ích cho RF-2 là 2 và đối với EC 2+1 sẽ là 1,5.
Để mô tả đơn giản hơn, bản chất là khối ảo được chia thành 2-8 (tại sao từ 2 đến 8, xem bên dưới) “mảnh” và đối với những mảnh này, “mảnh” chẵn lẻ có khối lượng tương tự được tính toán.
Kết quả là dữ liệu và tính chẵn lẻ được phân bổ đồng đều trên tất cả các nút của cụm. Đồng thời, giống như sao chép, ARDFS tự động phân phối dữ liệu giữa các nút theo cách ngăn dữ liệu giống hệt nhau (bản sao dữ liệu và tính chẵn lẻ của chúng) được lưu trữ trên cùng một nút, nhằm loại bỏ nguy cơ mất dữ liệu do đến thực tế là dữ liệu và tính chẵn lẻ của chúng sẽ đột nhiên xuất hiện trên một nút lưu trữ bị lỗi.
Dưới đây là một ví dụ, với cùng một máy ảo 8 MB và 4 nút, nhưng có sơ đồ EC 2+1.
Khối A và B được chia thành hai phần, mỗi phần có dung lượng 2 MB (hai phần vì 2+1), tức là A1+A2 và B1+B2. Không giống như bản sao, A1 không phải là bản sao của A2, nó là khối A ảo, được chia thành hai phần, giống với khối B. Tổng cộng, chúng ta có hai bộ 4 MB, mỗi bộ chứa hai phần 2 MB. Tiếp theo, đối với mỗi bộ này, tính chẵn lẻ được tính với dung lượng không quá một phần (tức là 2 MB), chúng ta thu được thêm + 4 phần chẵn lẻ (AP và BP). Tổng cộng chúng ta có dữ liệu 2×2 + tính chẵn lẻ 2×XNUMX.
Tiếp theo, các phần được “bố trí” giữa các nút để dữ liệu không giao nhau với tính chẵn lẻ của chúng. Những thứ kia. A1 và A2 sẽ không nằm trên cùng một nút với AP.
Trong trường hợp một nút bị lỗi (ví dụ, cũng là nút thứ ba), khối B1 bị rơi sẽ tự động được khôi phục từ tính chẵn lẻ BP, được lưu trữ trên nút số 2 và sẽ được kích hoạt trên nút có không có tính chẵn lẻ B, tức là mảnh BP. Trong ví dụ này, đây là nút số 1
Tôi chắc chắn rằng người đọc có một câu hỏi:
“Mọi thứ bạn mô tả đều đã được cả các đối thủ cạnh tranh và trong các giải pháp nguồn mở triển khai từ lâu, sự khác biệt giữa việc triển khai EC trong ARDFS của bạn là gì?”
Và sau đó sẽ có những tính năng thú vị của ARDFS.
Xóa mã hóa tập trung vào tính linh hoạt
Ban đầu, chúng tôi cung cấp sơ đồ EC X+Y khá linh hoạt, trong đó X bằng một số từ 2 đến 8 và Y bằng một số từ 1 đến 8, nhưng luôn nhỏ hơn hoặc bằng X. Sơ đồ này được cung cấp cho sự linh hoạt. Việc tăng số lượng phần dữ liệu (X) mà khối ảo được chia vào cho phép giảm chi phí chung, tức là tăng không gian sử dụng.
Việc tăng số lượng khối chẵn lẻ (Y) làm tăng độ tin cậy của đĩa ảo. Giá trị Y càng lớn thì càng có nhiều nút trong cụm có thể bị lỗi. Tất nhiên, việc tăng khối lượng chẵn lẻ sẽ làm giảm dung lượng khả dụng, nhưng đây là cái giá phải trả cho độ tin cậy.
Sự phụ thuộc của hiệu suất vào các mạch EC gần như trực tiếp: càng nhiều “mảnh”, hiệu suất càng thấp; ở đây tất nhiên cần có một cái nhìn cân bằng.
Cách tiếp cận này cho phép quản trị viên định cấu hình bộ nhớ mở rộng với độ linh hoạt tối đa. Trong nhóm ARDFS, bạn có thể sử dụng bất kỳ sơ đồ dung sai lỗi nào và sự kết hợp của chúng, theo quan điểm của chúng tôi, điều này cũng rất hữu ích.
Dưới đây là bảng so sánh một số sơ đồ RF và EC (không phải tất cả đều có thể).
Bảng này cho thấy rằng ngay cả sự kết hợp “terry” nhất EC 8+7, cho phép mất đồng thời tới 7 nút trong một cụm, “ngốn” ít không gian có thể sử dụng hơn (1,875 so với 2) so với bản sao tiêu chuẩn và bảo vệ tốt hơn 7 lần , điều này làm cho cơ chế bảo vệ này, mặc dù phức tạp hơn, hấp dẫn hơn nhiều trong các tình huống cần đảm bảo độ tin cậy tối đa trong điều kiện dung lượng ổ đĩa hạn chế. Đồng thời, bạn cần hiểu rằng mọi “cộng” với X hoặc Y sẽ là một chi phí bổ sung về hiệu suất, vì vậy trong tam giác giữa độ tin cậy, tiết kiệm và hiệu suất, bạn cần phải lựa chọn thật cẩn thận. Vì lý do này, chúng tôi sẽ dành một bài viết riêng để xóa kích thước mã hóa.
Độ tin cậy và quyền tự chủ của hệ thống tập tin
ARDFS chạy cục bộ trên tất cả các nút của cụm và đồng bộ hóa chúng bằng các phương tiện riêng thông qua giao diện Ethernet chuyên dụng. Điểm quan trọng là ARDFS đồng bộ hóa độc lập không chỉ dữ liệu mà còn cả siêu dữ liệu liên quan đến lưu trữ. Trong khi làm việc trên ARDFS, chúng tôi đã nghiên cứu đồng thời một số giải pháp hiện có và phát hiện ra rằng nhiều giải pháp đồng bộ hóa meta hệ thống tệp bằng cách sử dụng DBMS phân tán bên ngoài. Chúng tôi cũng sử dụng giải pháp này để đồng bộ hóa nhưng chỉ dùng cho cấu hình chứ không phải siêu dữ liệu FS (về điều này và các hệ thống con liên quan khác). ở bài viết tiếp theo).
Tất nhiên, đồng bộ hóa siêu dữ liệu FS bằng DBMS bên ngoài là một giải pháp hiệu quả, nhưng khi đó tính nhất quán của dữ liệu được lưu trữ trên ARDFS sẽ phụ thuộc vào DBMS bên ngoài và hành vi của nó (và nói thẳng ra, đó là một cô gái thất thường), điều này trong ý kiến của chúng tôi là xấu Tại sao? Nếu siêu dữ liệu FS bị hỏng thì bản thân dữ liệu FS cũng có thể được nói "tạm biệt", vì vậy chúng tôi đã quyết định đi theo con đường phức tạp hơn nhưng đáng tin cậy hơn.
Chúng tôi đã tự tạo hệ thống con đồng bộ hóa siêu dữ liệu cho ARDFS và hệ thống này hoạt động hoàn toàn độc lập với các hệ thống con liền kề. Những thứ kia. không có hệ thống con nào khác có thể làm hỏng dữ liệu ARDFS. Theo chúng tôi, đây là cách đáng tin cậy và đúng đắn nhất, nhưng thời gian sẽ trả lời liệu điều này có thực sự như vậy hay không. Ngoài ra, có một lợi thế bổ sung với phương pháp này. ARDFS có thể được sử dụng độc lập với vAIR, giống như bộ lưu trữ mở rộng mà chúng tôi chắc chắn sẽ sử dụng trong các sản phẩm trong tương lai.
Do đó, bằng cách phát triển ARDFS, chúng tôi đã nhận được một hệ thống tệp linh hoạt và đáng tin cậy cho phép bạn lựa chọn trong đó bạn có thể tiết kiệm dung lượng hoặc từ bỏ mọi thứ về hiệu suất hoặc tạo ra bộ lưu trữ cực kỳ đáng tin cậy với chi phí hợp lý nhưng giảm yêu cầu về hiệu suất.
Cùng với chính sách cấp phép đơn giản và mô hình phân phối linh hoạt (trong tương lai, vAIR được cấp phép theo nút và được phân phối dưới dạng phần mềm hoặc dưới dạng gói phần mềm), điều này giúp có thể điều chỉnh giải pháp một cách chính xác cho nhiều yêu cầu khác nhau của khách hàng và sau đó dễ dàng duy trì sự cân bằng này.
Ai cần điều kỳ diệu này?
Một mặt, chúng tôi có thể nói rằng trên thị trường đã có những người chơi có giải pháp nghiêm túc trong lĩnh vực siêu hội tụ và đây chính là nơi chúng tôi thực sự đang hướng tới. Có vẻ như tuyên bố này là đúng, NHƯNG...
Mặt khác, khi chúng tôi ra hiện trường và giao tiếp với khách hàng, chúng tôi và các đối tác của mình thấy rằng hoàn toàn không phải như vậy. Có rất nhiều nhiệm vụ dành cho siêu hội tụ, ở một số nơi, mọi người chỉ đơn giản là không biết rằng các giải pháp như vậy tồn tại, ở những nơi khác, nó có vẻ đắt tiền, ở những nơi khác, các thử nghiệm giải pháp thay thế không thành công và ở những nơi khác, họ cấm mua hoàn toàn do lệnh trừng phạt. Nói chung là ruộng chưa cày nên đi cày đất trinh))).
Khi nào hệ thống lưu trữ tốt hơn GCS?
Khi làm việc với thị trường, chúng tôi thường được hỏi khi nào nên sử dụng sơ đồ cổ điển với hệ thống lưu trữ và khi nào nên sử dụng siêu hội tụ? Nhiều công ty sản xuất GCS (đặc biệt là những công ty không có hệ thống lưu trữ trong danh mục đầu tư của họ) nói: “Hệ thống lưu trữ đang trở nên lỗi thời, chỉ có siêu hội tụ!” Đây là một tuyên bố táo bạo, nhưng nó không hoàn toàn phản ánh thực tế.
Trên thực tế, thị trường lưu trữ thực sự đang hướng tới các giải pháp siêu hội tụ và các giải pháp tương tự, nhưng luôn có một chữ “nhưng”.
Thứ nhất, các trung tâm dữ liệu và cơ sở hạ tầng CNTT được xây dựng theo sơ đồ cổ điển với hệ thống lưu trữ không thể dễ dàng xây dựng lại nên việc hiện đại hóa và hoàn thiện cơ sở hạ tầng đó vẫn là một di sản kéo dài 5 - 7 năm.
Thứ hai, cơ sở hạ tầng hiện đang được xây dựng phần lớn (có nghĩa là Liên bang Nga) được xây dựng theo sơ đồ cổ điển sử dụng hệ thống lưu trữ, không phải vì mọi người không biết về siêu hội tụ mà vì thị trường siêu hội tụ là mới, các giải pháp và Tiêu chuẩn chưa được thiết lập, dân IT chưa được đào tạo, ít kinh nghiệm nhưng cần xây dựng trung tâm dữ liệu ngay tại chỗ. Và xu hướng này sẽ kéo dài thêm 3-5 năm nữa (và sau đó là một di sản khác, xem điểm 1).
Thứ ba, có một giới hạn thuần túy về mặt kỹ thuật trong độ trễ nhỏ bổ sung là 2 mili giây cho mỗi lần ghi (tất nhiên không bao gồm bộ đệm cục bộ), đó là chi phí lưu trữ phân tán.
Chà, đừng quên việc sử dụng các máy chủ vật lý lớn yêu thích việc chia tỷ lệ theo chiều dọc của hệ thống con đĩa.
Có nhiều nhiệm vụ cần thiết và phổ biến trong đó hệ thống lưu trữ hoạt động tốt hơn GCS. Tất nhiên, ở đây, những nhà sản xuất không có hệ thống lưu trữ trong danh mục sản phẩm của họ sẽ không đồng ý với chúng tôi, nhưng chúng tôi sẵn sàng tranh luận một cách hợp lý. Tất nhiên, chúng tôi, với tư cách là nhà phát triển của cả hai sản phẩm, chắc chắn sẽ so sánh hệ thống lưu trữ và GCS trong một trong những ấn phẩm trong tương lai của chúng tôi, nơi chúng tôi sẽ chứng minh rõ ràng cái nào tốt hơn trong những điều kiện nào.
Và giải pháp siêu hội tụ sẽ hoạt động tốt hơn hệ thống lưu trữ ở đâu?
Dựa trên những điểm trên, có thể rút ra ba kết luận rõ ràng:
- Khi độ trễ bổ sung 2 mili giây để ghi, điều này luôn xảy ra ở bất kỳ sản phẩm nào (bây giờ chúng ta không nói về chất tổng hợp, nano giây có thể được hiển thị trên chất tổng hợp), là không quan trọng, thì siêu hội tụ là phù hợp.
- Khi tải từ các máy chủ vật lý lớn có thể được chuyển thành nhiều máy chủ ảo nhỏ và phân bổ giữa các nút, siêu hội tụ cũng sẽ hoạt động tốt ở đó.
- Khi chia tỷ lệ theo chiều ngang được ưu tiên cao hơn tỷ lệ theo chiều dọc, GCS cũng sẽ hoạt động tốt ở đó.
Những giải pháp này là gì?
- Tất cả các dịch vụ cơ sở hạ tầng tiêu chuẩn (dịch vụ thư mục, thư, EDMS, máy chủ tệp, hệ thống ERP và BI vừa và nhỏ, v.v.). Chúng tôi gọi đây là “điện toán tổng quát”.
- Cơ sở hạ tầng của các nhà cung cấp đám mây, nơi cần phải mở rộng nhanh chóng và chuẩn hóa theo chiều ngang và dễ dàng “cắt giảm” một số lượng lớn máy ảo cho khách hàng.
- Cơ sở hạ tầng máy tính để bàn ảo (VDI), nơi nhiều máy ảo người dùng nhỏ chạy và lặng lẽ “nổi” trong một cụm thống nhất.
- Mạng chi nhánh, trong đó mỗi chi nhánh cần có cơ sở hạ tầng tiêu chuẩn, có khả năng chịu lỗi nhưng không tốn kém gồm 15-20 máy ảo.
- Bất kỳ điện toán phân tán nào (ví dụ như dịch vụ dữ liệu lớn). Nơi mà tải trọng không đi “theo chiều sâu” mà là “theo chiều rộng”.
- Môi trường thử nghiệm có thể chấp nhận được độ trễ nhỏ bổ sung nhưng có những hạn chế về ngân sách vì đây là những thử nghiệm.
Hiện tại, chúng tôi đã thực hiện AERODISK vAIR cho những nhiệm vụ này và chúng tôi đang tập trung vào chúng (cho đến nay đã thành công). Có lẽ điều này sẽ sớm thay đổi, bởi vì... thế giới không đứng yên.
Vì thế…
Điều này hoàn thành phần đầu tiên của một loạt bài viết dài; trong bài viết tiếp theo chúng ta sẽ nói về kiến trúc của giải pháp và các thành phần được sử dụng.
Chúng tôi hoan nghênh các câu hỏi, đề xuất và tranh chấp mang tính xây dựng.
Nguồn: www.habr.com