Giới thiệu về Hỗ trợ Native Metro Volume với Ví dụ về PowerStore CLI

Giới thiệu

Với hỗ trợ khối lượng metro gốc, PowerStoreOS 3.0 giới thiệu một tính năng bổ sung giúp ngăn chặn sản xuất của bạn khỏi tình trạng ngừng hoạt động do lỗi trong môi trường VMware vSphere Metro Storage Cluster (vMSC) của bạn . Tính năng Metro Volume có sẵn mà không mất thêm chi phí trên PowerStore và có thể được sử dụng để bảo vệ kho dữ liệu VMFS.

Cấu hình vMSC là kiến ​​trúc cụm kéo dài, trong đó máy chủ ESXi có thể ở hai vị trí khác nhau trong khoảng cách đô thị (100 km / 60 dặm) trong khi truy cập vào tài nguyên lưu trữ được sao chép đồng bộ. Tính năng PowerStore Metro Volume cung cấp IO máy chủ hoạt động/hoạt động đồng thời và đầy đủ trên cả hai cấu hình cụm PowerStore tham gia.

Mặc dù điều này làm tăng thêm độ trễ, PowerStore Metro Volume đảm bảo rằng tất cả các I/O của máy chủ được cam kết trên cả hai khối lượng phản chiếu của Metro Volume trước khi máy chủ nhận được xác nhận cho I/O ghi. Để tồn tại sau thảm họa với mức gián đoạn tối thiểu hoặc thậm chí tốt hơn là không gián đoạn quá trình sản xuất của bạn, PowerStore đã tích hợp một cơ chế để bảo vệ dữ liệu của bạn khỏi tình huống não chia đôi trong trường hợp xảy ra lỗi hoặc thảm họa. PowerStore được thiết kế để chỉ cho phép các khối lượng công việc hoạt động-hoạt động ở cả hai bên của Metro Volume khi dữ liệu có thể được sao chép giữa các khối lượng phản chiếu Metro Volume trên cả hai cụm PowerStore.

Theo quan điểm về cấu trúc, PowerStore hỗ trợ hai kịch bản cấu hình khác nhau. Có một cấu hình Không đồng nhất trong đó máy chủ chỉ có quyền truy cập vào hệ thống PowerStore cục bộ:

Ngoài ra còn có cấu hình Uniform cho phép máy chủ có thể truy cập cả PowerStore cục bộ và từ xa.

Mặc dù trông có vẻ giống nhau, nhưng lợi ích của các cấu trúc mạng khác nhau nằm ở các chi tiết.

Cấu hình máy chủ không đồng nhất làm giảm độ phức tạp vì nó yêu cầu ít cấu hình hơn và chỉ cung cấp quyền truy cập cục bộ vào ổ đĩa có mức sử dụng ít nhất trên liên kết giữa hai trang web. Tuy nhiên, trong tình huống lỗi với mảng PowerStore cục bộ hoặc trong quá trình liên kết lỗi, máy chủ cục bộ có thể mất quyền truy cập vào Metro Volume. Trong tình huống này, VMware HA cần khởi động lại bất kỳ VM nào trên kho dữ liệu bị ảnh hưởng bằng cách sử dụng các máy chủ còn sống trên trang web đối diện. Phải có đủ tài nguyên máy chủ khả dụng trên mỗi trang web để cho phép chạy các VM quan trọng nhất trong khi trang web ngang hàng không khả dụng.

Trong cấu hình máy chủ đồng nhất, các máy chủ có các liên kết bổ sung đến cụm PowerStore từ xa có thể được sử dụng trong trường hợp lỗi. Nếu Metro Volume không thể truy cập được trên cụm PowerStore cục bộ do lỗi hoặc mất liên kết, các máy chủ có thể sử dụng các liên kết chéo để truy cập vào ổ đĩa trên trang web từ xa. Trong trường hợp này, VM có thể tồn tại sau lỗi vì máy chủ có thể chuyển đường dẫn làm việc sang hệ thống từ xa. Trong các hoạt động bình thường, I/O của máy chủ phải được giữ trong trang web cục bộ để tránh sử dụng băng thông không cần thiết trên liên kết giữa các trang web cho khối lượng công việc và để giảm thiểu độ trễ.

Để tôi cho bạn xem một ví dụ nhanh trong đó chúng ta giả định độ trễ cục bộ lý thuyết là 0,5ms và 2ms giữa các địa điểm.

1. Máy chủ đang sử dụng liên kết đến mảng cục bộ làm đường dẫn chính để ghi vào Metro Volume. Độ trễ lý thuyết cho I/O sẽ như sau:

• Khối lượng công việc 0,5ms từ máy chủ đến bộ lưu trữ cục bộ
• 2.0ms để sao chép khối lượng công việc vào bộ lưu trữ từ xa. Khối lượng công việc sử dụng liên kết giữa các trang web.
• 2.0ms để nhận cam kết từ bộ lưu trữ từ xa trên bộ lưu trữ cục bộ
• 0,5ms cho cam kết với máy chủ

Tổng cộng, chúng ta sẽ thấy độ trễ 5,0ms cho I/O và khối lượng công việc chỉ được gửi một lần qua liên kết giữa các trang web để sao chép (AB).

2. Khi máy chủ sử dụng các liên kết đến mảng từ xa làm đường dẫn chính, chúng ta sẽ thấy tình huống sau:

• 2.0ms để gửi khối lượng công việc đến bộ lưu trữ từ xa. Khối lượng công việc sử dụng liên kết giữa các trang web.
• 2.0ms để sao chép khối lượng công việc cho một đối tác. Khối lượng công việc sử dụng liên kết giữa các trang web.
• 2.0ms cho cam kết từ mảng ngang hàng đến bộ lưu trữ từ xa
• 2.0ms cho cam kết với máy chủ

Tổng cộng, chúng ta sẽ thấy độ trễ lý thuyết là 8,0ms cho cùng một I/O vì khối lượng công việc và các cam kết luôn sử dụng liên kết giữa các trang web: một lần, khi máy chủ ghi dữ liệu vào mảng từ xa (A đến B) và một lần nữa khi dữ liệu ghi được sao chép vào bộ lưu trữ ngang hàng (BA) cộng với các cam kết bắt buộc.

Để đảm bảo lựa chọn đường dẫn tối ưu, PowerStore cung cấp thông tin để lựa chọn đường dẫn tối ưu bằng giao thức Truy cập đơn vị logic không đồng bộ (ALUA). Đối với trạng thái ALUA chính xác, các máy chủ thống nhất phải được đăng ký với mối quan hệ cục bộ hoặc từ xa của chúng với mỗi cụm PowerStore. Có bốn tùy chọn khi đăng ký máy chủ trong PowerStore Manager:

• Chỉ cục bộ – Được sử dụng cho các khối lượng Metro không đồng nhất và các máy chủ chỉ phục vụ các khối lượng tiêu chuẩn.
• Máy chủ đồng vị trí với hệ thống PowerStore này – Chỉ ra rằng máy chủ ở vị trí cục bộ (độ trễ thấp) đối với PowerStore và sẽ có các đường dẫn hoạt động/tối ưu hóa ALUA.
• Máy chủ được đặt cùng vị trí với hệ thống PowerStore từ xa – Chỉ ra rằng máy chủ là máy chủ từ xa (độ trễ cao) và máy chủ phải có đường dẫn ALUA đang hoạt động/chưa được tối ưu hóa.
• Máy chủ được đặt cùng vị trí với cả hai – Chỉ ra rằng tất cả máy chủ và cụm PowerStore đều nằm ở cùng một vị trí với cùng độ trễ.

Khi máy chủ được cấu hình với tùy chọn kết nối metro cho Uniform Metro Volume, PowerStore cung cấp thông tin đường dẫn ALUA mặc định cho các ổ đĩa chuẩn không phải metro.

Với chính sách lựa chọn đường dẫn (PSP) mặc định của Native Multipathing (NMP) là “round robin” (RR), các máy chủ ESXi được kết nối sử dụng thông tin đường dẫn ALUA được cung cấp để xác định đường dẫn làm việc tối ưu xuống ổ đĩa. Khi có nhiều hơn một đường dẫn hoạt động/được tối ưu hóa, ESXi PSP round robin sẽ đo độ trễ đến ổ đĩa để chọn đường dẫn làm việc tối ưu nhất. Đường dẫn làm việc hiện tại được chỉ định bằng trạng thái “Hoạt động (I/O)” trong vCenter, trong khi các đường dẫn khác chỉ hiển thị trạng thái “Hoạt động”. Hình sau đây hiển thị trạng thái đường dẫn cho máy chủ ESXi trong cấu hình máy chủ Uniform sau khi cấu hình Metro Volume hoàn tất.

Sau khi các máy chủ được thiết lập trong trình quản lý PowerStore, chúng ta có thể bắt đầu cấu hình Metro Volume. Điều này có thể thực hiện chỉ trong vài bước trên một cụm PowerStore duy nhất:

1. Để thiết lập mối quan hệ Hệ thống từ xa với PowerStore ngang hàng, hãy chọn Bảo vệ > Thêm Hệ thống từ xa .
2. Sử dụng trình hướng dẫn Thêm ổ đĩa để tạo và ánh xạ một ổ đĩa chuẩn.
3. Trong trang Volumes, hãy cấu hình Metro Volume bằng sáu lần nhấp.

a. Chọn ổ đĩa mới.

b. Nhấp vào Bảo vệ .

c.  Cấu hình Metro Volume

d. Nhấp vào danh sách thả xuống Hệ thống từ xa  .

e. Chọn một hệ thống từ xa hiện có (hoặc thiết lập mối quan hệ hệ thống từ xa mới với cụm PowerStore khác).

f. Nhấp vào cấu hình để bắt đầu cấu hình.

4. Trên cụm PowerStore ngang hàng, ánh xạ Metro Volume mới tới các máy chủ.

5. Sử dụng Metro Volume mới để tạo kho dữ liệu VMFS.

Ngoài việc sử dụng PowerStore Manager, bạn cũng có thể sử dụng PowerStore REST API hoặc PowerStore CLI để thiết lập Metro Volume chỉ trong vài bước. Trong blog này, tôi muốn chỉ cho bạn các bước cần thiết trong phiên PowerStore CLI ( pstcli -d <PowerStore> -session ) để thiết lập Metro Volume trên PowerStore trên một cặp hệ thống PowerStore đã cấu hình (như trong hình trước) để kết nối máy chủ thống nhất:

1. Trên PowerStore Manager PowerStore-A

a.   Tạo  mối quan hệ Hệ thống từ xa:

x509_certificate exchange -service Replication_HTTP -address <Địa chỉ IP PowerStore-B> -port 443 -username admin -password <YourSecretPassword>
 remote_system create -management_address <Địa chỉ IP PowerStore-B> -management_port 443 -remote_username admin -remote_password <YourSecretPassword> -type PowerStore -data_network_latency Thấp

b.  Đăng ký máy chủ ESXi để kết nối máy chủ thống nhất:

máy chủ tạo -tên esx-a.lab -kiểu_hệ_thống ESXi -người khởi tạo -tên_cổng iqn.1998-01.com.vmware:esx-a:<…>:65 -kiểu_cổng iSCSI -kết_nối_máy_chủ Metro_Optimize_Local
máy chủ tạo -tên esx-b.lab -kiểu_hệ_thống ESXi -người khởi tạo -tên_cổng  iqn.1998-01.com.vmware:esx-b:<…>:65 -kiểu_cổng iSCSI -kết_nối_máy_chủ Metro_Optimize_Remote

c.  Chuẩn bị và lập bản đồ thể tích chuẩn:

tạo khối lượng -tên MetroVolume-Uniform -kích thước 1T
volume -name MetroVolume-Uniform -attach esx-a.lab
volume -name MetroVolume-Uniform -attach esx-b.lab

d.  Cấu hình ổ đĩa dưới dạng Ổ đĩa Metro:

volume -name MetroVolume-Uniform configure_metro -remote_system_name PowerStore-B

2. Trên PowerStore Manager PowerStore-B

a.  Đăng ký máy chủ ESXi để kết nối máy chủ thống nhất:

máy chủ tạo -tên esx-a.lab -kiểu_hệ_thống ESXi -người khởi tạo -tên_cổng iqn.1998-01.com.vmware:esx-a:<…>:65 -kiểu_cổng iSCSI -kết_nối_máy_chủ Metro_Optimize_Remote
máy chủ tạo -tên esx-b.lab -kiểu_hệ_thống ESXi -người_khởi_tạo -tên_cổng iqn.1998-01.com.vmware:esx-b:<…>:65 -kiểu_cổng iSCSI -kết_nối_máy_chủ Metro_Optimize_Local

b.   Ánh xạ Volume tới máy chủ ESXi:

volume -name MetroVolume-Uniform -attach esx-a.lab
volume -name MetroVolume-Uniform -attach esx-b.lab

c.   Giám sát Metro Volume (tùy chọn):

replication_session show -query type=Metro_Active_Active -select state,progress_percentage,data_transfer_state

3. Trong vCenter

a. Quét lại bus SCSI.

b. Cấu hình kho dữ liệu VMFS với Metro Volume mới.