Nghỉ ngơi trên vòng nguyệt quế của chúng ta – Có gì mới với API PowerMax và Unisphere 10.1

Unisphere 10.1 vừa mới được phát hành! Mặc dù tên mã nội bộ là Laurel, chúng tôi đang làm rất nhiều trong API, vì vậy chúng tôi chắc chắn không nghỉ ngơi trên vòng nguyệt quế của mình!

Với bản phát hành này, nhóm Unisphere for PowerMax tập trung vào những gì có thể làm tốt hơn trong PowerMax API, để giúp các nhà phát triển dễ dàng hơn và giảm lượng mã mà mọi người phải duy trì để làm việc với PowerMax API. Cá nhân tôi nghĩ rằng họ đã làm rất tốt với một số tính năng mới. Những tính năng này đặt nền tảng cho nhiều tính năng tương tự trong tương lai. Như thường lệ, có một nhật ký thay đổi đầy đủ cho API được công bố cùng với các tài liệu OpenAPI được cập nhật có sẵn trên https://developer.dell.com . Trong blog này, tôi cung cấp quan điểm của riêng mình và nêu bật một số lĩnh vực mà tôi nghĩ sẽ giúp ích cho bạn với tư cách là khách hàng.

Hãy bắt đầu với API Unisphere for PowerMax truyền thống. Với phiên bản mới này của Unisphere, có một phiên bản API mới và tham chiếu phiên bản đơn giản hơn trong toàn bộ API. Ví dụ, lệnh gọi API GET version sau trả về api_version (trong trường hợp này là 101) và các phiên bản API hiện được hỗ trợ với bản phát hành này (101, 100 và 92). Như thường lệ, hai phiên bản trước đó được hỗ trợ. Ở đây, khóa supported_api_versions giúp loại bỏ mọi phỏng đoán khỏi phương trình. Nếu bạn đang sử dụng PyU4V, phiên bản mới (10.1) sẽ khả dụng, hỗ trợ tất cả các chức năng mới được đề cập ở đây.

https://Unisphere:8443/univmax/restapi/version (LẤY)
{
  "phiên bản": "T10.1.0.468",
  "api_version": "101",
  "supported_api_versions": [
    "101",
    "100",
    "92"
  ]
}

Tôi sẽ phân tích các thay đổi khác theo tài nguyên chức năng để bạn có thể bỏ qua bất kỳ thay đổi nào mà bạn không sử dụng:

• Các cuộc gọi API về khả năng bảo trì
• Cải tiến cuộc gọi sao chép
• Cải tiến cuộc gọi Sloprovisioning
• Cải tiến cuộc gọi hệ thống
• Cải tiến cuộc gọi API hiệu suất
• API PowerMax hoàn toàn mới được cải tiến – Gọi API hàng loạt

Các cuộc gọi API về khả năng bảo trì

Đối với người dùng Unisphere for PowerMax nhúng, khi hệ thống được cập nhật lên phiên bản Unipshere mới nhất, một Tài nguyên API khả năng bảo trì mới sẽ khả dụng.

Các lệnh gọi API khả năng bảo trì mới (như thể hiện trong hình sau) cung cấp quyền kiểm soát Unisphere được nhúng, cung cấp quyền truy cập vào các cài đặt kích hoạt giải pháp và các cài đặt Unisphere cho đến nay chỉ có thể truy cập được trong UI, chẳng hạn như:

• Thiết lập tệp nethosts để truy cập máy khách/máy chủ từ máy chủ CLI đang chạy Solutions Enabler
• Kiểm soát truy cập dựa trên máy chủ
• Quản lý chứng chỉ của hệ điều hành khách Solutions Enabler
• Và nhiều hơn nữa

Sau đây là sơ đồ cây tài nguyên API khả năng phục vụ:

Lưu ý : Khi thực hiện lệnh gọi API để cập nhật ứng dụng Unisphere, máy chủ sẽ khởi động lại do những thay đổi này. Bạn phải đợi những lệnh này hoàn tất trước khi có thể thực hiện thêm lệnh gọi API. Ngoài ra, để nhắc nhở, nếu bạn đang thay đổi địa chỉ IP của máy chủ Unisphere, bạn phải cập nhật kết nối API của mình cho các lệnh gọi trong tương lai.

Cải tiến cuộc gọi sao chép

Tin tốt cho khách hàng sử dụng snapshot và chính sách snapshot. Các lệnh gọi và khóa sao chép mới sẽ giúp quy trình quản lý dễ dàng hơn cho bất kỳ ai tự động hóa kiểm soát snapshot và sử dụng chính sách.

Cuộc gọi API được cập nhật sẽ thêm khóa cho các chính sách được liên kết trực tiếp so với các chính sách được kế thừa:

101/replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId} (LẤY)

Trong API, việc xác định và theo dõi các ảnh chụp nhanh được liên kết ngược đã tốn nhiều thời gian trong quá khứ. Dựa trên phản hồi có giá trị của khách hàng, bộ phận quản lý sản phẩm và nhà phát triển của chúng tôi đã triển khai các thay đổi quan trọng sẽ giúp ích.

Khả năng liệt kê các nhóm lưu trữ được liên kết với các mục tiêu đã có từ lâu, với các tham số truy vấn trong lệnh gọi GET sau:

101/replication/symmetrix/{symmetrixId}/storagegroup?is_link_target=true

Tuy nhiên, việc tìm ra snapshot nào được liên kết và nhóm lưu trữ nguồn nào sở hữu snapshot đó là một thách thức. Để làm cho việc này dễ dàng hơn, các khóa mới hiện xuất hiện:

101/replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId} (LẤY)

Như bạn có thể thấy, lệnh gọi API 10.1 trả về một khóa mới ( snapshot_link_info ) bao gồm tất cả thông tin bạn cần để có thể thao tác các ảnh chụp nhanh được liên kết mà không cần phải tự mình thực hiện bất kỳ thủ thuật nào.

Cải tiến cuộc gọi Sloprovisioning

Có lẽ thay đổi lớn nhất đối với các lệnh gọi API Provisioning là khả năng Xác thực và trả về Yêu cầu xấu khi performance_impact_validation_option được đặt để sloprovisoning lệnh gọi POST /maskingview. Điều này cung cấp cho nhà phát triển một cách để kiểm tra, tại thời điểm cung cấp, liệu khối lượng công việc có phù hợp để chạy trên số sê-ri PowerMax được cung cấp hay không. Lệnh gọi này sử dụng dữ liệu hiệu suất từ ​​cơ sở dữ liệu trình lập kế hoạch khối lượng công việc và có thể giúp tạo khối lượng công việc cung cấp nâng cao với hiệu suất và phân vùng trong tâm trí.

Payload hiện có thể chấp nhận khóa mới ( performance_impact_validation_option ) có thể được đặt thành:

• IfRecommended – Chạy thử nghiệm tác động hiệu suất. Nếu không có ngưỡng năng lực hiệu suất nào bị vi phạm, hãy chạy thay đổi cấu hình theo yêu cầu.
• Xem trước – Chạy thử nghiệm tác động hiệu suất và trả về điểm tác động hiệu suất cho hoạt động được yêu cầu. Trả về đối tượng đầu vào (với các trường được tạo, nếu có) cho các cuộc gọi API theo dõi có liên quan.

Ngoài ra, payload có khóa “portGroupSelection” có thể tự động tạo nhóm cổng mới hoặc sử dụng nhóm cổng hiện có. Nếu sử dụng lựa chọn tự động, lựa chọn có thể là UtilizationBased hoặc ZoningBased. ( Lưu ý : Lựa chọn cổng tự động chỉ khả dụng cho Fibre (SCSI FC)) 

Nếu bạn chọn sử dụng một nhóm cổng hiện có, các nhóm cổng hiện có sẽ được đánh giá bởi các thuật toán lập kế hoạch khối lượng công việc kiểm tra các nhóm cổng đã được cấu hình trên hệ thống. Thuật toán sẽ chọn nhóm cổng ít tải nhất để cung cấp và bỏ qua phân vùng. Người dùng có Tùy chọn hạn chế lựa chọn vào danh sách các nhóm cổng được cung cấp bằng cách sử dụng các khóa API. Xem tài liệu để biết chi tiết về các khóa khác nhau.

Lưu ý : Khi sử dụng lựa chọn tác động hiệu suất, bạn không thể chỉ định nhóm lưu trữ hiện có vì giả định rằng chúng đã được cung cấp. Tài liệu đầy đủ về lệnh gọi API được đề cập có tại đây với các tham số được hỗ trợ.

Các lệnh gọi API cung cấp bao gồm các bổ sung khác:

• Cập nhật POST cho Create Masking View, để cho phép chỉ định Địa chỉ LUN Bắt đầu. Đây là cải tiến của khách hàng để giúp cấu hình khởi động từ SAN dễ dàng hơn.
• Cập nhật PUT cho Modify SG để cho phép chỉ định Địa chỉ LUN bắt đầu khi thêm ổ đĩa.
• Cập nhật PUT cho Modify SG, để cho phép chấm dứt snapshot liên quan đến các volume bị xóa khỏi SG trong một lần gọi. Điều này rất hữu ích vì nó ngăn các snapshot bị kẹt chiếm không gian trên mảng.

Cải tiến cuộc gọi hệ thống

Chúng tôi đã thêm các lệnh gọi hệ thống để cho phép làm mới Unisphere. Điều này hữu ích cho những khách hàng đang làm việc trong môi trường phân tán và muốn đảm bảo dữ liệu Unisphere được cập nhật thông tin mới nhất từng giây. Trường hợp này là có thể, nhưng trong trường hợp có những thay đổi được thực hiện trên hệ thống từ xa, có thể mất khoảng một phút trước khi những thay đổi này được phản ánh trong mô hình đối tượng. Lệnh gọi làm mới mới có một số hạn chế, ở chỗ bạn chỉ có thể chạy lệnh này một lần sau mỗi năm phút. Nếu bạn cố thực thi quá sớm, mã trạng thái 429 sẽ trả về với thông báo yêu cầu bạn đợi lệnh này trả về:

“Phản hồi không mong muốn hoặc không hợp lệ từ API backend của khối lượng lưu trữ: Lỗi POST Không có tài nguyên. Mã trạng thái nhận được là 429 và thông báo là {'retry_after_ms': 285417}.”

Tài liệu cho lệnh gọi API này ( /101/system/symmetrix/{array_serial}/refresh ) có tại đây .

Trước đây, việc lấy thông tin về tài nguyên REST API và việc sử dụng máy chủ chỉ khả dụng trong giao diện người dùng. Việc cung cấp thông tin này thông qua REST API là hợp lý vì thông tin liên quan đến REST. Lệnh gọi GET mới để lấy thông tin này ( /101/system/management_server_resources ) đã khả dụng, tài liệu ở đây .

Tương tự như vậy, chúng tôi cũng đã thêm các lời kêu gọi sau:

• Mức Nhật ký Thay đổi – /101/system/logging (PUT/GET)
• Cấu hình/Kiểm tra đích SNMP – /101/system/snmp (GET/POST/PUT/DELETE)
  • Quản lý chứng chỉ máy chủ – /101/system/snmp/server_cert (POST)
  • Cấu hình SNMPv3 với TLS – /101/system/snmp/v3_tls (POST)
• Quản lý cấp phép PowerMax qua API

Cải tiến hiệu suất cuộc gọi API

Chỉ có một thay đổi nhỏ trong API truyền thống về hiệu suất với bản phát hành này. Chúng tôi đang thêm khả năng đăng ký danh sách các nhóm lưu trữ để có hiệu suất thời gian thực và cũng đưa số liệu tệp cho SDNAS vào mảng Unisphere for PowerMax để theo dõi. Lệnh gọi POST /performance/Array/register đã được cập nhật để lấy khóa mới, selectedSG và tệp.

Tải trọng mới sẽ trông giống như thế này:

{
   "symmetrixId":  "01234568779" ,
   "selectedSGs":  "sg1, sg2, sg3" ,
  "diagnostic":  "true " ,
   "realtime":  "true" ,
   "file":  "true" 
}

Có một số thay đổi bổ sung cho máy chủ lớn và Workload Planner được đề cập trong tài liệu nhật ký thay đổi. Tôi chỉ muốn nêu bật ở đây những gì tôi nghĩ hầu hết khách hàng sẽ quan tâm và cung cấp một số thông tin cơ bản.

API PowerMax hoàn toàn mới được cải tiến – Gọi API hàng loạt

Tôi đã mong chờ được công bố một số cải tiến rất tuyệt vời cho API PowerMax. API cung cấp các lệnh gọi mới với các tài nguyên có thể truy cập theo một URI cơ sở khác. Thay vì https:// {server_ip}:{port}/univmax/restapi/, các lệnh gọi API mới nằm trong https://{server_ip}:{port}/univmax/rest/v1.

Sự khác biệt giữa hai điểm nhập cảnh sẽ trở nên rõ ràng khi bạn quen với các lệnh gọi này và việc quản lý phiên bản sẽ trở nên đơn giản hơn trong tương lai. Tài liệu có tại đây .

• NHẬN – /hệ thống/{id}/khối lượng
• NHẬN – /hệ thống/{id}/nhóm lưu trữ
• NHẬN – /hệ thống/{id}/thể loại-hiệu suất
• NHẬN – /hệ thống/{id}/thể loại-hiệu suất/{id}

Để biết thông tin chi tiết về các điểm cuối này, hãy xem:

• Tài liệu API được đánh dấu là “POWERMAX – ENHANCED ENDPOINTS”
• Nhật ký thay đổi API REST của Unisphere cho PowerMax 10.1

“Được rồi” Tôi nghe bạn nói, “vậy thì vấn đề lớn là gì?”. Vâng, các điểm cuối này hoạt động khác với các lệnh gọi API hiện tại của chúng tôi. Chúng cung cấp nhiều thông tin nhanh hơn để các nhà phát triển không phải duy trì nhiều mã để có được thông tin họ cần.

Lệnh gọi Volumes GET trả về thông tin chi tiết về mọi volume trên một hệ thống chỉ trong một lệnh gọi. Không cần phân trang và bạn không cần lo lắng về trình lặp hoặc phải xử lý bất kỳ thứ gì phức tạp. API chỉ trả về cho bạn một phản hồi JSON lớn với tất cả thông tin bạn cần. Điều này loại bỏ nhu cầu lặp lại các lệnh gọi và sẽ cắt giảm đáng kể số lượng lệnh gọi API bạn cần gửi đến máy chủ.

Tương tự như vậy đối với các cuộc gọi nhóm lưu trữ. Chỉ với một cuộc gọi, bạn có thể nhận được thông tin về tất cả các nhóm lưu trữ trên hệ thống, thuộc tính của chúng và các ổ đĩa nào nằm trong các nhóm đó.

Nhưng hãy đợi đã, vẫn còn nữa…

Chúng tôi đã triển khai một hình thức lọc phản hồi đã sửa đổi. Bây giờ bạn có thể lọc tất cả các thuộc tính và các thuộc tính lồng nhau được trả về trong phản hồi: 

../nhóm-lưu-trữ?filter=cap_gb eq 100 
../storage-groups?filter=volumes.wwn như 12345678

Các tùy chọn bộ lọc có sẵn là:

Các điểm cuối yêu cầu bạn phải “chọn” các thuộc tính mong muốn thay vì trả về mọi thứ ngay từ đầu. Bằng cách đó, bạn có thể kiểm soát mức độ chuyên sâu của máy chủ đối với mỗi yêu cầu bằng cách bỏ qua hoặc chỉ bao gồm thông tin có liên quan:

…/nhóm-lưu-trữ?chọn=cap_gb,uuid,loại,số_lượng_khối_lượng

Lệnh này chỉ trả về cap_gb,uuid, type và num_of_volumes cho mỗi nhóm lưu trữ.

Điều này cũng áp dụng cho các thuộc tính lồng nhau (dấu chấm được sử dụng để xác định các thuộc tính con):

…/nhóm-lưu-trữ?select=volumes.wwn,volumes.effective_wwn,snapshots.timestamp_ms

Nếu không có thuộc tính nào được xác định trong “select”, chỉ các giá trị mặc định, chẳng hạn như “id”, được trả về. Danh sách các thuộc tính có thể được chọn có trong tài liệu tại đây .

Các hàm cũng có sẵn cho việc này trong PyU4V. Hiện tại, nhiều tùy chọn bộ lọc được kết hợp trong một mẫu AND và select có thể được áp dụng cho dữ liệu để giảm đầu ra xuống chỉ còn những gì bạn quan tâm. Sau đây là một ví dụ về chức năng này được thực hiện thông qua PyU4V 10.1:  

Với chức năng mới này, bạn có thể nhận được mọi thông tin chi tiết về các ổ đĩa và nhóm lưu trữ của mình chỉ trong hai lần gọi trên mỗi mảng, giảm từ hàng chục nghìn lần gọi trên các hệ thống lớn hơn.

Số liệu hiệu suất được cải thiện với Bulk API mới

Ngoài các lệnh gọi GET mới cho các nhóm Volumes và Storage, còn có các lệnh gọi mới cho số liệu hiệu suất.

Lệnh gọi /systems/{id}/performance-categories (GET) trả về danh sách các danh mục hiệu suất hợp lệ cho mảng bạn đang truy vấn. 

Khi bạn truy vấn từng danh mục, API sẽ trả về khoảng thời gian cuối cùng của dữ liệu hiệu suất chẩn đoán bằng lệnh gọi GET /systems/{id}/performance-categories/{id} mới. Lệnh này sẽ trả về tất cả các số liệu chỉ số hiệu suất chính ở cấp độ chẩn đoán cho danh mục và tất cả các trường hợp trong danh mục đó trong năm phút cuối.

Các lệnh gọi API nâng cao mới này làm giảm lượng mã mà các nhà phát triển cần viết và duy trì. Lệnh gọi API được thiết kế có chủ đích để chỉ cung cấp thông tin mới nhất. Điều này làm giảm lượng mã mà các nhà phát triển cần duy trì việc thu thập dữ liệu hiệu suất cho các công cụ loại bảng điều khiển và trình thu thập dữ liệu.

Ví dụ sau đây cho thấy một tập lệnh PyU4V thực thi một vài dòng mã để thu thập tất cả số liệu thống kê hiệu suất cho mọi danh mục trên mọi thành phần của mảng PowerMax. Nó cũng thu thập thông tin chi tiết về tất cả các ổ đĩa và tất cả các nhóm lưu trữ bằng cách sử dụng các lệnh gọi API nâng cao mới. Trên hệ thống của tôi, mã mất trung bình khoảng tám giây để thu thập tất cả thông tin đó.

Để kết thúc

Hy vọng blog này đã cung cấp một số thông tin chi tiết về những thay đổi mới nhất trong PowerMax REST API. Như bạn có thể thấy, các nhà phát triển của chúng tôi đã không RESTing trên vòng nguyệt quế của họ!