vRealize Automation và VMware Solution Self-Service Hybrid Cloud Hyperscalers

vRealize Automation Cloud và vRealize Automation 8.4 (v3) hiện đã được kiểm tra và chứng nhận hoạt động với các giải pháp đám mây được lưu trữ trên máy chủ của VMware trên Microsoft Azure, Google Cloud Platform, Oracle Cloud và Dell EMC, lần lượt là Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Solution (OCVS) và VMware Cloud on Dell EMC. Bên cạnh đó, VMware Cloud on AWS (VMC trên AWS) cũng đã được hỗ trợ từ khá lâu.

Giới thiệu chung

Điều này có nghĩa là khối lượng công việc riêng của khách hàng cũng như VMware  có trong vSphere Cloud riêng tư của có thể chạy liền mạch trên Giải pháp Azure VMware, Google Cloud VMware Engine, VMware Cloud on AWS, VMware Oracle Solution và VMware Cloud on Dell EMC sau đó chúng sẽ được quản lý bởi vRealize Automation sau khi thiết lập tài khoản đám mây vCenter và NSX-T thích hợp.

Khả năng này mang lại giá trị và mở ra nhiều trường hợp sử dụng cho việc mở rộng trung tâm dữ liệu trong tương lai từ các đám mây riêng sang nhiều đám mây công cộng, khắc phục thảm họa, tính liền mạch trong kinh doanh, các dự án phát triển ứng dụng hiện đại và tích hợp với Public Cloud Native Services.

Tuy nhiên, có một số điều và những khác biệt nhỏ cần lưu ý mà chúng ta sẽ cùng thảo luận ở phần tiếp theo của bài viết. Vì vậy, chúng ta hãy xem xét cấu hình tích hợp và vRealize Automation cũng như khám phá cách mà khách hàng có thể tận dụng Tài nguyên đám mây công cộng gốc trong loại thiết lập này.

Tích hợp vRealize Automation

Đối với hầu hết các phần, việc tích hợp với vRealize Automation khá giống với việc thêm bất kỳ điểm cuối vSphere nào hoặc phiên bản NSX-T tại chỗ (nếu khách hàng đang sử dụng vRealize Automation Cloud, họ cũng sẽ cần triển khai Cloud Proxy).

Có một ngoại lệ (tích cực) đó là trong trường hợp VMware Cloud on AWS, khách hàng chỉ cần cung cấp mã thông báo VMware Cloud on AWS API, sau đó vRealize Automation sẽ kéo điểm cuối vSphere liên quan và phiên bản NSX-T có sẵn tại VMware Cloud on SDDC của AWS. Tất cả những gì khách hàng cần làm là cung cấp mật khẩu cho vCenter của mình và (hoặc) thay đổi tên người dùng vCenter mặc định.

Khách hàng cũng cần lưu ý rằng mỗi nhà cung cấp đám mây công cộng sẽ cung cấp cho khách hàng đám mây riêng có chứa các cụm VMware vSphere, vCenter Server, vSAN và NSX-T được xây dựng trên cơ sở hạ tầng đám mây công cộng bare-metal chuyên dụng.

Nói một cách đơn giản, có thể các bản phát hành VMware SDDC khác nhau được hỗ trợ tùy thuộc vào Nhà cung cấp dịch vụ đám mây. Trên thực tế, tại thời điểm bài viết này được đăng tải đã có các phiên bản mới nhất có sẵn như sau:

• CGVE: VMware vSphere phiên bản 7.0 | NSX-T phiên bản 3.0
• AVS: VMware vSphere phiên bản 6.7U3I | NSX-T phiên bản 2.5.2
• OCVE: VMware vSphere phiên bản 7.0 U1 | NSX-T phiên bản 3.0.2.0
• VMC: VMware vSphere phiên bản 7.0.2 | NSX-T phiên bản 3.0.3
• VMC trên Dell: VMware vSphere phiên bản 7.0

Điều này sẽ dẫn đến hệ quả trong cách chúng ta tích hợp vRealize Automation. Ví dụ: Bất cứ khi nào thêm điểm cuối NSX-T trên phiên bản 3.0, chúng ta có tùy chọn để chọn Chế độ NSX: Chính sách hoặc Trình quản lý, Chính sách là định nghĩa API mới, cũng cho phép vRealize Automation có các khả năng mới hơn. chẳng hạn như có thể tạo nhóm bảo mật NSX-T.

Xin lưu ý rằng NSX không được hiển thị như một điểm cuối trong VMware Cloud trên Dell EMC. Do đó, vRealize Automation không thể tương tác trực tiếp với NSX Manager trong VMware Cloud trên môi trường Dell EMC và chỉ có mạng vSphere làm được điều đó. Ngoài ra, chế độ cấu hình DNS trong VMware Cloud on Dell SDDC của EMS phải được thiết lập đúng cách để phân giải IP công cộng hoặc riêng tư của FQDN vCenter, điều này tùy thuộc vào nhu cầu môi trường của khách hàng.

Ngoài ra còn có các cấp độ truy cập và vai trò khác nhau được Nhà cung cấp Đám mây Công cộng triển khai cho giải pháp VMware SDDC, đặc biệt là xoay quanh chức năng cụ thể ở các cấp độ thấp hơn. Ví dụ: Azure VMware Solution thực hiện vai trò CloudAdmin tương tự như VMware Cloud on AWS nhưng có sự khác biệt, Azure VMware Solution sử dụng “Không có quyền truy cập” vào Management VMs / Resource Pools trong Host và Cluster and Folders view in vSphere client. Do đó, các máy ảo quản lý không hiển thị với vai trò CloudAdmin.

Từ thời điểm này, việc tạo và định cấu hình các thành phần vRealize Automation (tức Cloud Zones, Networks / Storage Profiles, Flavors / Images Mappings, Projects, v.v.) là trải nghiệm giống nhau trên các nền tảng khác nhau.

Điều gì sẽ xảy ra nếu VMware triển khai cùng một khối lượng công việc trên tất cả các Public Cloud (Azure VMware Solution,  Google Cloud VMware Engine, VMware Cloud on AWS và Oracle Cloud VMware Solution) và Private Cloud (vSphere trên phần mềm tại chỗ)? Chúng ta hãy xem nó diễn ra như thế nào.

Triển khai công việc trên Public Cloud

Với mục đích này, chúng ta hãy cùng triển khai Cloud Template duy nhất cung cấp Mạng NAT NSX mới, một số Disk Volumes và một Sphere VM (đã đính kèm các Disk Volumes bằng cách chỉ ra rõ ràng Bộ điều khiển SCSI và Số đơn vị):

VMware cũng muốn nhấn mạnh rằng chúng ta đang sử dụng cùng một Cloud Template, một tạo tác duy nhất sẽ được triển khai bởi vRealize Automation on Azure VMware Solution, Google Cloud VMware Engine, VMware Cloud on AWS và Oracle Cloud VMware Solution Public Clouds và Private Cloud (vSphere On-Prem của công ty).

Ngoài ra, khi được triển khai bởi vRealize Automation, trải nghiệm người dùng là giống nhau, bất kể Cloud Provider “Hyperscaler” được người dùng chọn là gì:

Các hoạt động ngày 2, những tùy chỉnh luôn có sẵn cho tất cả các tài nguyên, các hành động mở rộng được thực thi liền mạch cho tất cả các môi trường, Custom Properties và quy ước đặt tên theo Dự án được thực hiện đúng thời hạn. Việc gắn thẻ, kết hợp với nhau và các Chính sách quản trị phù hợp đều được thực thi. Lưu ý rằng ngày hết hạn là như nhau đối với tất cả các lần triển khai kể cả Cloud Provide bằng cách chỉ cần áp dụng chính sách của vRealize Automation Organization xung quanh Cloud.vSphere.Machine. VMware cũng có thể xác định các chính sách cụ thể hơn, dựa trên Cloud Provide “Hyperscaler” hoặc các tiêu chí khác.

Như có thể thấy, thực sự không có sự khác biệt khi nói đến trải nghiệm người dùng, tất cả đều cho phép khách hàng mở rộng quy mô hoặc giảm tải Khối lượng công việc trên Private Cloud của mình vào các nhà cung cấp Public Cloud mà khách hàng yêu thích mà không phải trải qua các thay đổi trong việc thực hiện vRealize Automation.

Về Cloud Public Native Services, VMware đã tạo một Cloud Template khác, (hình bên dưới) sẽ triển khai Azure Resource Group, Azure SQL Server và Azure SQL Database, sau đó FrontEnd vSphere VM tại Azure VMware Solution sẽ sử dụng Azure SQL Database (và tận dụng khả năng mở rộng, bảo mật, khả năng phục hồi của chúng, v.v.)

Điều tương tự có thể được thực hiện với VMware Cloud on AWS và RDS, chúng ta cũng không đi sâu vào chi tiết cụ thể của việc thiết lập kết nối mạng thích hợp, theo ý của nhà cung cấp. Trong ví dụ này, VMware đang sử dụng Azure VMware Solution Backbone Network để cung cấp kết nối IP qua VNETs cho Azure VMware Solution và Azure Native Services.

Cuối cùng, công ty VMware muốn chỉ ra rằng vRealize Automation Project lưu trữ Cloud Template này có quyền truy cập Azure VMware Solution Cloud Zone cũng như Azure Cloud Zone, nơi có thể tạo tài nguyên Azure gốc.

Khi được triển khai, chúng ta có thể thấy cách một Cloud Template có thể được sử dụng để triển khai khối lượng công việc phức tạp kết hợp VMware Solution trong Public Cloud với Native Cloud Services, tất cả đều có Danh mục quản trị và tự phục vụ được quản lý, v.v.

Từ vSphere VM, chúng ta có thể kết nối với Azure MS SQL của mình và chèn, cập nhật và truy vấn dữ liệu từ Azure Native SQL DB mới được tạo.

sqlcmd -S tcp:moff-sql-server.database.windows.net,1433 -d acctest-db-d -U myadministrator -N -l 30

VMware đã chạy các câu lệnh T-SQL sau để cập nhật cột DriverID và OriginCity

1> UPDATE Drivers SET OriginCity=’Boston’ WHERE DriverID=123;
2> GO (1 rows affected)

Chúng ta có thể xác minh bản cập nhật bằng một truy vấn đơn giản

1> SELECT DriverID, OriginCity FROM Drivers;
2> GO
DriverID OriginCity

123 Boston

Chúng ta có thể tiến thêm một bước nữa bằng cách chuyển đầu ra Azure MS SQL vào vSphere VM và biến nó thành FrontEnd WebServer thông qua Cloud-Init hoặc vRealize SaltStack Configuration.

Tiếp đó, chúng ta có thể nhận thấy Terraform Construct trong đó, VMware muốn bảo mật quyền truy MS SQL Database và chỉ giới hạn quyền truy cập vào IP được cấp phát tại FrontEnd vSphere VM và chúng ta có thể đã thực hiện điều này bằng ABX Extensibility Action nhưng Terraform Azure Firewall Rule đã tồn tại và nó cũng sẽ xóa quy tắc tại Deployment delete, vì vậy chúng ta đã sử dụng quy tắc này thay thế.

Phần kết luận:

vRealize Automation Cloud và vRealize Automation 8.4 (v3) đã được chứng nhận để hoạt động với Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Solution (OCVS), VMware Cloud on AWS (VMC trên AWS) và VMware Cloud trên Dell EMC sẽ đơn giản hóa và nâng cao hành trình của khách hàng đến Hybrid Cloud.

Biên dịch bởi Tuyết Hiền – Iworld.com.vn