Một trong những người chơi trẻ trong thị trường giải pháp khắc phục thảm họa là Hystax, một công ty khởi nghiệp của Nga vào năm 2016. Vì chủ đề khắc phục thảm họa rất phổ biến và thị trường cực kỳ cạnh tranh nên công ty khởi nghiệp quyết định tập trung vào việc di chuyển giữa các cơ sở hạ tầng đám mây khác nhau. Một sản phẩm cho phép bạn tổ chức di chuyển lên đám mây một cách đơn giản và nhanh chóng sẽ rất hữu ích cho khách hàng - người dùng của Onlanta . Đó là cách tôi biết đến Hystax và bắt đầu thử nghiệm các tính năng của nó. Và điều gì đã xảy ra, tôi sẽ kể trong bài viết này.
Tính năng chính của Hystax là chức năng rộng rãi để hỗ trợ nhiều nền tảng ảo hóa, hệ điều hành khách và dịch vụ đám mây khác nhau, giúp bạn có thể di chuyển khối lượng công việc của mình từ mọi nơi và mọi nơi.
Điều này cho phép bạn không chỉ tạo ra các giải pháp DR để cải thiện khả năng chịu lỗi của dịch vụ mà còn di chuyển nhanh chóng, linh hoạt các tài nguyên giữa các địa điểm và bộ siêu quy mô khác nhau để tăng tiết kiệm chi phí và chọn giải pháp tốt nhất cho một dịch vụ cụ thể tại thời điểm hiện tại. Ngoài các nền tảng được liệt kê trong hình tiêu đề, công ty còn tích cực hợp tác với các nhà cung cấp đám mây của Nga: Yandex.Cloud, CROC Cloud Services, Mail.ru và nhiều nền tảng khác. Điều đáng chú ý là vào năm 2020, công ty đã mở một trung tâm R&D đặt tại Skolkovo.
Việc nhiều người chơi trên thị trường lựa chọn một giải pháp cho thấy chính sách giá tốt và tính ứng dụng cao của sản phẩm mà chúng tôi quyết định thử nghiệm trên thực tế.
Vì vậy, nhiệm vụ thử nghiệm của chúng tôi sẽ bao gồm việc di chuyển từ trang web thử nghiệm VMware và các máy vật lý của tôi sang trang web của nhà cung cấp cũng chạy VMware. Đúng, có nhiều giải pháp có thể triển khai quá trình di chuyển như vậy, nhưng chúng tôi coi Hystax là một công cụ phổ quát và việc thử nghiệm quá trình di chuyển theo tất cả các kết hợp có thể chỉ đơn giản là một nhiệm vụ phi thực tế. Có, và đám mây Oncloud.ru được xây dựng riêng trên VMware, vì vậy nền tảng này, với tư cách là mục tiêu, khiến chúng tôi quan tâm nhiều hơn. Tiếp theo, tôi sẽ mô tả nguyên tắc hoạt động cơ bản, nhìn chung không phụ thuộc vào nền tảng và VMware có thể được thay thế từ bất kỳ phía nào bằng nền tảng từ nhà cung cấp khác.
Bước đầu tiên là triển khai Hystax Acura, đây là bảng điều khiển của hệ thống.
Nó mở rộng từ mẫu. Vì lý do nào đó, trong trường hợp của chúng tôi, điều đó không hoàn toàn chính xác và thay vì 8CPU được đề xuất, 16Gb đã được triển khai với một nửa tài nguyên. Do đó, bạn cần nhớ thay đổi chúng, nếu không cơ sở hạ tầng bên trong VM, nơi mọi thứ được xây dựng trên đó, sẽ không khởi động được bằng các thùng chứa và cổng sẽ không khả dụng. TRONG các tài nguyên cần thiết được mô tả chi tiết cũng như các cổng cho tất cả các thành phần hệ thống.
Và cũng có những khó khăn trong việc thiết lập địa chỉ IP thông qua mẫu nên chúng tôi đã thay đổi nó từ bảng điều khiển. Sau đó, bạn có thể truy cập giao diện web quản trị và hoàn tất trình hướng dẫn cấu hình ban đầu.
Điểm cuối - IP hoặc FQDN của vCenter của chúng tôi.
Đăng nhập và mật khẩu - ở đây rõ ràng.
Tên máy chủ ESXi mục tiêu là một trong những máy chủ trong cụm của chúng tôi sẽ được sao chép sang.
Kho dữ liệu mục tiêu là một trong những kho dữ liệu trong cụm của chúng tôi sẽ được sao chép sang.
IP công cộng của bảng điều khiển Hystax Acura - địa chỉ nơi bảng điều khiển sẽ có sẵn.
Cần làm rõ một chút về máy chủ và kho dữ liệu. Thực tế là bản sao Hystax hoạt động ở cấp độ máy chủ và kho dữ liệu. Tiếp theo, tôi sẽ cho bạn biết cách bạn có thể thay đổi máy chủ và kho dữ liệu cho đối tượng thuê, nhưng vấn đề lại khác. Hystax không hỗ trợ tổng hợp tài nguyên, tức là. bản sao sẽ luôn xảy ra với thư mục gốc của cụm (tại thời điểm viết tài liệu này, những người từ Hystax đã phát hành một phiên bản cập nhật, nơi họ nhanh chóng triển khai yêu cầu tính năng của tôi về hỗ trợ cho nhóm tài nguyên). Ngoài ra vCloud Director không được hỗ trợ, tức là. như trong trường hợp của tôi, nếu đối tượng thuê không có quyền quản trị đối với toàn bộ cụm mà chỉ có một nhóm tài nguyên cụ thể và chúng tôi đã cấp quyền truy cập vào Hystax, thì anh ta sẽ có thể sao chép và chạy các máy ảo này một cách độc lập, nhưng anh ta sẽ không thể nhìn thấy chúng trong cơ sở hạ tầng VMware mà anh ta có quyền truy cập và theo đó, quản lý thêm các máy ảo. Quản trị viên cụm cần di chuyển VM đến đúng nhóm tài nguyên hoặc nhập nó vào vCloud Director.
Tại sao tôi lại tập trung nhiều vào những khoảnh khắc này? Bởi vì, theo như tôi hiểu về khái niệm sản phẩm, khách hàng sẽ có thể thực hiện độc lập mọi hoạt động di chuyển hoặc DR bằng bảng điều khiển Acura. Nhưng cho đến nay, sự hỗ trợ của VMware vẫn chậm hơn một chút so với mức hỗ trợ cho OpenStack tương tự, nơi các cơ chế như vậy đã được triển khai.
Nhưng quay lại việc triển khai. Trước hết, sau khi thiết lập bảng điều khiển ban đầu, chúng ta cần tạo đối tượng thuê đầu tiên trong hệ thống của mình.
Tất cả các trường ở đây đều rõ ràng, tôi sẽ chỉ nói với bạn về trường Đám mây. Chúng tôi đã có đám mây "mặc định" mà chúng tôi đã tạo trong quá trình cấu hình ban đầu. Nhưng nếu chúng tôi muốn có thể đặt từng đối tượng thuê vào kho dữ liệu riêng và trong nhóm tài nguyên riêng của họ, thì chúng tôi có thể triển khai điều này bằng cách tạo các đám mây riêng cho từng khách hàng của mình.
Trong hình thức thêm đám mây mới, chúng tôi chỉ định các tham số tương tự như trong cấu hình ban đầu (thậm chí chúng tôi có thể sử dụng cùng một máy chủ), chỉ định kho dữ liệu cần thiết cho một khách hàng cụ thể và giờ đây, trong các tham số bổ sung, chúng tôi có thể chỉ định riêng tài nguyên nhóm bắt buộc {"resource_pool" :"YOUR_POOL_NAME"}
Như bạn có thể nhận thấy, trong hình thức tạo đối tượng thuê, không có gì liên quan đến việc phân bổ tài nguyên hoặc một số loại hạn ngạch - không có điều gì như vậy trong hệ thống. Bạn không thể giới hạn đối tượng thuê về số lượng bản sao đồng thời, số lượng máy để sao chép hoặc bằng bất kỳ tham số nào khác. Vì vậy, chúng tôi đã tạo đối tượng thuê đầu tiên. Bây giờ có một điều không hoàn toàn hợp lý nhưng bắt buộc - cài đặt tác nhân Đám mây. Điều này là phi logic vì tác nhân được tải xuống trên trang của một khách hàng cụ thể.
Đồng thời, nó không bị ràng buộc với đối tượng thuê đã tạo và tất cả khách hàng của chúng tôi sẽ xử lý nó (hoặc sau một số khách hàng, nếu chúng tôi triển khai chúng). Một tác nhân hỗ trợ 10 phiên đồng thời. Một buổi được tính là một chiếc ô tô. Không quan trọng nó có bao nhiêu đĩa. Cho đến nay, không có cơ chế mở rộng quy mô tác nhân trong chính Acura cho VMware. Còn một khoảnh khắc khó chịu nữa - chúng tôi không thể xem xét việc "sử dụng" tác nhân này từ bảng điều khiển Acura để kết luận liệu chúng tôi cần triển khai thêm hay cài đặt hiện tại là đủ. Kết quả là giá đỡ trông như thế này:
Bước tiếp theo để truy cập cổng thông tin khách hàng của chúng tôi là tạo một tài khoản (và trước tiên, cũng là một vai trò sẽ được áp dụng cho người dùng này).
Bây giờ khách hàng của chúng tôi có thể sử dụng cổng thông tin một cách độc lập. Tất cả những gì anh ta cần làm là tải các tác nhân xuống từ cổng và cài đặt chúng về phía mình. Có ba loại tác nhân: Linux, Windows và VMware.
Hai cái đầu tiên được đưa vào vật lý hoặc trên các máy ảo trên bất kỳ trình ảo hóa không phải VMware nào. Không có cấu hình bổ sung nào được yêu cầu ở đây, đại lý tải xuống và đã biết nơi để gõ, và theo đúng nghĩa đen, sau một phút nữa, chiếc xe sẽ hiển thị trong bảng điều khiển Acura. Với tác nhân VMware, tình hình phức tạp hơn một chút. Vấn đề là Agent cho VMware cũng được tải xuống từ cổng đã được chuẩn bị sẵn và có cấu hình cần thiết. Nhưng tác nhân VMware, ngoài việc biết về cổng Acura của chúng tôi, còn cần biết về hệ thống ảo hóa mà nó sẽ được triển khai trên đó.
Trên thực tế, hệ thống sẽ yêu cầu chúng tôi chỉ định dữ liệu này khi bạn tải xuống tác nhân VMware lần đầu tiên. Vấn đề là trong thời đại chúng ta yêu thích bảo mật, không phải ai cũng muốn chỉ ra mật khẩu quản trị viên của mình trên cổng thông tin của người khác, điều này khá dễ hiểu. Từ bên trong, sau khi triển khai, tác nhân không thể được cấu hình theo bất kỳ cách nào (bạn chỉ có thể thay đổi cài đặt mạng của nó). Ở đây tôi thấy trước những khó khăn với những khách hàng đặc biệt thận trọng.
Vì vậy, sau khi cài đặt các đại lý, chúng ta có thể quay lại bảng điều khiển Acura và xem tất cả các xe của mình.
Vì tôi đã làm việc với hệ thống được hơn một ngày nên tôi có máy ở nhiều tiểu bang khác nhau. Tất cả chúng đều nằm trong nhóm Mặc định, nhưng có thể tạo các nhóm riêng biệt và chuyển máy sang chúng nếu bạn cần. Điều này không ảnh hưởng gì cả - chỉ có sự biểu diễn logic của dữ liệu và việc nhóm chúng để làm việc thuận tiện hơn. Điều đầu tiên và quan trọng nhất chúng ta cần làm sau đó là bắt đầu quá trình di chuyển. Chúng tôi có thể thực hiện việc này một cách bắt buộc theo cách thủ công và thiết lập lịch trình, bao gồm hàng loạt cho tất cả các máy cùng một lúc.
Hãy để tôi nhắc bạn rằng Hystax được định vị là một sản phẩm dành cho việc di chuyển. Do đó, không có gì ngạc nhiên khi để chạy các máy nhân bản của mình, chúng tôi cần tạo gói DR. Bạn có thể tạo gói cho các máy đã ở trạng thái Đã đồng bộ hóa. Bạn có thể tạo cả hai cho một VM cụ thể và cho tất cả các máy cùng một lúc.
Tập hợp các tham số khi tạo gói DR sẽ khác nhau tùy thuộc vào cơ sở hạ tầng mà bạn sẽ di chuyển. Có sẵn một bộ tùy chọn tối thiểu cho môi trường VMware. Re-IP cho máy cũng không được hỗ trợ. Về vấn đề này, chúng tôi quan tâm đến các điểm sau: trong mô tả về VM, tham số “mạng con”: “VMNetwork”, nơi chúng tôi liên kết VM với một mạng cụ thể trong cụm. Xếp hạng - phù hợp khi di chuyển một số máy ảo, xác định thứ tự chúng được khởi chạy. Flavor mô tả cấu hình VM, trong trường hợp này là 1CPU, RAM 2GB. Trong phần mạng con, chúng tôi xác định rằng “mạng con”: “VMNetwork” được liên kết với “VM Network” của VMware.
Khi tạo gói DR, không có cách nào để “phân chia” các đĩa trên các kho dữ liệu khác nhau. Chúng sẽ nằm trên cùng một kho dữ liệu đã được xác định cho đám mây khách này và nếu bạn có các đĩa thuộc các lớp khác nhau, điều này có thể gây ra một số khó khăn khi khởi động máy và sau khi khởi động và “tách” VM khỏi Hystax, nó cũng sẽ yêu cầu một đĩa di chuyển riêng biệt tới các kho dữ liệu cần thiết. Sau đó, chúng tôi chỉ cần chạy kế hoạch DR của mình và đợi xe của chúng tôi tăng lên. Quá trình chuyển đổi P2V/V2V cũng mất thời gian. Trên máy thử nghiệm 100GB lớn nhất của tôi có ba ổ đĩa, quá trình này mất tối đa 10 phút.
Sau đó, bạn nên kiểm tra VM đang chạy, các dịch vụ trên đó, tính nhất quán của dữ liệu và các kiểm tra khác.
Khi đó chúng ta có hai lựa chọn:
- Xóa - xóa gói DR đang chạy. Hành động này sẽ chỉ tắt máy ảo đang chạy. Những bản sao này sẽ không đi đâu cả.
- Tách ra - xé chiếc xe được sao chép từ Acura, tức là. thực sự hoàn thành quá trình di chuyển.
Ưu điểm của giải pháp:
- dễ dàng cài đặt và cấu hình cả về phía khách hàng và phía nhà cung cấp;
- dễ dàng thiết lập di chuyển, tạo gói DR và khởi chạy bản sao;
- bộ phận hỗ trợ và nhà phát triển phản hồi khá nhanh với các vấn đề được tìm thấy và khắc phục chúng bằng các bản cập nhật nền tảng hoặc tác nhân.
Nhược điểm
- Hỗ trợ Vmware không đầy đủ.
- Không có bất kỳ hạn ngạch nào cho người thuê từ nền tảng.
Tôi cũng đã đưa ra Yêu cầu tính năng mà chúng tôi đã chuyển cho nhà cung cấp:
- giám sát và triển khai việc sử dụng từ Bảng điều khiển quản lý Acura dành cho Đại lý đám mây;
- có sẵn hạn ngạch cho người thuê nhà;
- khả năng giới hạn số lần sao chép đồng thời và tốc độ cho mỗi người thuê;
- hỗ trợ VMware vCloud Director;
- hỗ trợ cho nhóm tài nguyên (đã được triển khai trong quá trình thử nghiệm);
- khả năng định cấu hình tác nhân VMware từ phía chính tác nhân mà không cần nhập thông tin xác thực từ cơ sở hạ tầng máy khách trong bảng điều khiển Acura;
- "Trực quan hóa" quá trình khởi động VM khi bắt đầu gói DR.
Điều duy nhất khiến tôi phàn nàn lớn là tài liệu. Tôi thực sự không thích "hộp đen" và thích khi có tài liệu chi tiết về cách thức hoạt động của sản phẩm bên trong. Và nếu đối với AWS và OpenStack, sản phẩm thậm chí còn được mô tả ít nhiều thì đối với VMware có rất ít tài liệu.
Có Hướng dẫn cài đặt chỉ mô tả việc triển khai bảng điều khiển Acura và không có thông tin nào về sự cần thiết của tác nhân Đám mây. Có đầy đủ các thông số kỹ thuật cho sản phẩm, điều này là tốt. Có tài liệu mô tả quá trình thiết lập "từ và đến" bằng cách sử dụng AWS và OpenStack làm ví dụ (mặc dù nó khiến tôi nhớ đến một bài đăng trên blog hơn) và có một Cơ sở Kiến thức rất nhỏ.
Nói chung, đây không hẳn là định dạng tài liệu mà tôi thường sử dụng từ các nhà cung cấp lớn hơn, vì vậy tôi không hoàn toàn thoải mái. Đồng thời, tôi không tìm thấy câu trả lời về một số sắc thái hoạt động “bên trong” của hệ thống trong tài liệu này - tôi đã phải làm rõ rất nhiều câu hỏi với sự hỗ trợ kỹ thuật, và điều này làm kéo dài quá trình triển khai chân đế và thử nghiệm.
Tóm lại, tôi có thể nói rằng nhìn chung tôi thích sản phẩm và cách tiếp cận của công ty trong việc thực hiện nhiệm vụ. Đúng, có những sai sót, thiếu chức năng thực sự nghiêm trọng (kết hợp với VMware). Có thể thấy rằng, trước hết, công ty vẫn tập trung vào public cloud, đặc biệt là AWS, và đối với một số người thì điều này là đủ. Việc có được một sản phẩm đơn giản và tiện lợi như vậy hiện nay khi nhiều công ty lựa chọn chiến lược đa đám mây là điều vô cùng quan trọng. Với mức giá thấp hơn nhiều so với các đối thủ, điều này khiến sản phẩm trở nên vô cùng hấp dẫn.
Chúng tôi đang tìm kiếm một đội . Có lẽ đó là bạn?
Nguồn: www.habr.com
