Tweet
Ucs director
UCS DIRECTOR
Tự động hóa cho phép mở rộng cần thiết, cải tiến tốc độ và độ chính xác cần thiết để tăng tính sáng tạo và trả lời nhanh chóng cho các yêu cầu kinh doanh trong môi trường trung tâm dữ liệu. UCS Director thay thế các cấu hình thủ công và các tiến trình cài đặt với khả năng sắp xếp để tối ưu và đơn giản hóa các tài nguyên trung tâm dữ liệu.
Nền tảng private cloud giúp triển khai công nghệ hạ tầng như một dịch vụ (IaaS) từ lớp lõi đến lớp biên của một trung tâm dữ liệu. Các qui trình tự động hóa có thể cấu hình, triển khai và quản lý các tài nguyên hạ tầng trên các tài nguyên tính toán, mạng, các tài nguyên lưu trữ và các giải pháp hạ tầng hội tụ, siêu hội tụ. UCS Director hỗ trợ các giải pháp hàng đầu trong lĩnh vực công nghệ hạ tầng hội tụ, bao gồm NetApp FlexFod và FlexPod Express, EMC VSPEX, EMC VPLEX và VCE Block. Nó cung cấp các giải pháp quản trị hội tụ và sắp đặt cho các hypervisor thật và ảo.
Một trang portal tự phục vụ, một danh mục các dịch vụ hiện đại và hơn 2500 các tác vụ cho phép truy cập theo yêu cầu đến các dịch vụ tích hợp trên các tài nguyên trung tâm dữ liệu. UCS Director cho phép các kỹ sư IT chuyên nghiệp và các đội phần mềm có thể yêu cầu và sắp xếp các dịch vụ hạ tầng theo yêu cầu.
UCS Director được hỗ trợ bởi một hệ sinh thái rộng lớn. Các phần cứng và các giải pháp của bên thứ ba có thể sử dụng southbound API và SDK đi kèm để phát triển phần tích hợp vào bên trong mô hình quản trị của UCS Director. Northbound API có thể được dùng bởi DevOps và các đội quản lý vận hành IT để tương tác với UCS Director và thực thi tất cả các tác vụ cung cấp bởi giải pháp theo cách lập trình và tự động.
UCS Director cung cấp các chức năng nhận dạng xuyên suốt các dòng lưu lượng và các giải pháp quản tị của hạ tầng mạng trung tâm dữ liệu. Từ quan điểm quản trị trung tâm dữ liệu, chúng ta có thể thực hiện một số tác vụ với UCS Director:
Tạo, nhân bản và triển khai các hồ sơ dịch vụ và các khuôn mẫu cho tất cả các máy chủ UCS và các ứng dụng tính toán. Quản lý, giám sát và báo cáo trên các thành phần trung tâm dữ liệu, chẳng hạn như UCS domain hay các thiết bị Cisco Nexus. Giám sát việc sử dụng, các khuynh hướng và dung lượng trên một hạ tầng mạng hội tự theo một nền tảng liên tục. Triển khai và thêm vào dung lượng cho các hạ tầng mạng hội tụ theo cách nhất quán, lặp lại.
UCS Director cũng cho phép tạo ra các lưu đồ công việc để tự động hóa các dịch vụ. Các lưu đồ này được phổ biến và có sẵn cho người dùng cuối trên các trang web portal. Khi đã xây dựng và kiểm tra xong, các lưu đồ thực hiện lặp lại giống nhau mỗi lần, bất chấp ai là người kích hoạt chúng.
Người quản trị trung tâm dữ liệu có thể chạy chúng, hoặc các cơ chế phân quyền có thể giúp các người dùng và khách hàng chạy các tiến trình này theo mô hình tự phục vụ. Từ quan điểm tự động hóa hạ tầng, một vài trường hợp ứng dụng UCS Director có thể giúp tự động hóa bao gồm các tác vụ tạo mới máy ảo, quản lý các chu kỳ thiết bị, các tài nguyên tính toán, các mạng và các tài nguyên lưu trữ. Cài đặt các máy chủ vật lý, bao gồm cài đặt hệ điều hành
UCS Director hỗ trợ ACI bằng cách cung cấp các qui trình công việc tự động giúp sắp xếp các cấu hình APIC và các tác vụ quản lý. Nó cũng hỗ trợ các mô hình nhiều khách hàng và khả năng để định nghĩa các contracts giữa các lớp container khác nhau. UCS Director có thể được quản lý dùng Cisco Intersigh. UCS Director là một ứng dụng 64bit sử dụng Open Virtualization Format (OVF) trên VMWare Vsphere và Virtual Hard Disk (VHD) cho Microsoft Hyper-V.
Kế tiếp, chúng ta hãy điểm qua một số khái niệm quan trọng cần thiết để hiểu làm thế nào UCS Director có thể sắp xếp các công việc. Đầu tiên một tác vụ (task) là một đơn vị nhỏ nhất của công việc, nó không thể được chia thành các hành động nhỏ hơn và có thể đại diện bởi một hành động đơn lẻ có đầu vào và đầu ra. UCS Director có một thư viện chứa hàng trăm các tác vụ định nghĩa trước, chẳng hạn như các lệnh SSH (thực thi một lệnh trong một phiên SSH), một tác vụ thu thập các thiết bị, tác vụ tạo mới máy ảo và nhiều tác vụ khác. Trong trường hợp không có một tác vụ định nghĩa trước nào là phù hợp, hệ thống cho phép chúng ta tạo mới các tác vụ tùy biến.
Khái niệm thứ hai là lưu đồ công việc (workflow). Một lưu đồ công việc là một chuỗi của các hành động được sắp xếp để tự động hóa các tác vụ phức tạp. Một tác vụ đơn giản nhất sẽ chứa chỉ một tác vụ nhưng một lưu đồ công việc sẽ chứa một số bất kỳ các tác vụ. Workflow là trái tim của UCS Director. Nó tự động các tiến trình ở bất kỳ mức độ phức tạp nào.
Các lưu đồ công việc được xây dựng bằng công cụ Workflow Designer, là một giao tiếp dạng kéo và thả. Trong công cụ Workflow Designer, các tác vụ được sắp xếp tuần tự và định nghĩa các đầu vào, đầu ra cho các tác vụ này. Các vòng lặp và các điều kiện có thể được thực thi, một yêu cầu dịch vụ được tạo ra. Các lưu đồ công việc có thể được định thời để thực thi sau và UCS Director lưu trữ các chi tiết của các yêu cầu dịch vụ đã hoàn thành. Trong công cụ Workflow Designer, các tác vụ được sắp xếp tuần tự và định nghĩa các đầu vào, đầu ra cho các tác vụ này. Các vòng lặp và các điều kiện có thể được hiện thực bằng cách dùng các tác vụ kiểm soát dòng. Một yêu cầu dịch vụ có thể có vài trạng thái, tùy thuộc vào các mức độ thực thi của nó: định thời, chạy, ngăn chặn, hoàn thành hay bị thất bại. Cuối cùng, các thư viện và các catalog là tập hợp của các tác vụ định nghĩa trước có thể được dùng như là các khối cho các tác vụ lưu đồ công việc cao cấp hơn.
Bây giờ chúng ta hãy khảo sát khả năng mở rộng và khả năng lập trình của UCS Director. UCS director SDK là một tập hợp của các công nghệ cho phép các nhà phát triển ứng dụng mở rộng khả năng của UCS, truy cập đến dữ liệu UCS Director, kích hoạt tính năng tự động hóa của UCS và sắp xếp các tác vụ cho bất kỳ ứng dụng nào.
UCS Director SDK bao gồm các thành phần Open Automation. Các công nghệ Scripting bao gồm UCS Director PowerShell API, các tác vụ tùy chọn trong UCS Director mô-đun và khả năng để viết các tác vụ tùy chọn dùng CloupiaScript. Đây là một bản JavaScript server-side.
UCS Director SDK có khả năng thực hiện các việc sau:
Open Automation có thể được dùng để thêm vào các mô-đun cho UCS Director. Một mô-đun là một điểm tiếp nhận mức cao nhất của UCS Director. Để thêm vào hay mở rộng chức năng của hệ thống, một mô-đun mới phải được phát triển và triển khai trên UCS Director. Một mô-đun phát triển dùng Open Automation cũng hoạt động giống như các tính năng có sẵn của UCS Director hay các mô-đun khác. Open Automation là một SDK dùng JAVA và các frame work chứa tất cả các tài nguyên cần thiết để phát triển một mô-đun mới.
Một vài ứng dụng mới của Open Automation là:
Các tác vụ tùy biến được viết bằng CloudpiaScripts, một ngôn ngữ tựa như JavaScripts. Các tác vụ tùy biến có thể được dùng giống như các tác vụ nào khác, bao gồm các lưu đồ công việc sắp xếp cách thức các hệ thống làm việc. Các script bundle là một tập hợp của các tác vụ tùy biến bao gồm bên trong từng UCS Director và được dùng cho các ứng dụng cụ thể. Script bundle có thể được tải về và các tác vụ bên trong các bundle có thể được tải vào trong UCS Director. Mục đích chính của các tác vụ tùy biến là để mở rộng một loạt các tác vụ có sẵn để sử dụng trong các lưu đồ sắp đặt.
Các script mô-đun được dùng để tích hợp các JARs (Java Archive) của bên thứ ba và các thư viện của UCS Director để thêm vào các chức năng của UCS Director. Một vài hoạt động script mô-đun đã được định nghĩa trong UCS Director, chẳng hạn như tạo ra các chức năng điều khiển cao cấp để thu thập các thông tin đầu vào của người dùng cho các lưu đồ công việc và các ý nghĩa của các ngữ cảnh trong lưu đồ công việc. Chức năng này cho phép người quản trị kết hợp lưu đồ công việc với các hành động tùy biến trong một báo cáo đến UCS Director.
Các script mô-đun có thể được xuất ra và sử dụng trong các phiên bản khác của UCS Director. Các script mô-đun mặc dù có tên tương tự như script bundle, thật ra có vai trò rất khác biệt. Script bundle được đóng gói với một tập hợp của các tác vụ được phát hành chung với UCS Director. Các script mô-đun cho phép thêm các chức năng tùy biến vào UCS Director.
UCS Director PowerShell là một ứng dụng do Cisco phát triển cung cấp giao diện PowerShell đến UCS Director REST API. Chức năng console cung cấp tập hợp các PowerShell cmdlets được đóng gói trong một mô-đun để kích hoạt REST API thông qua HTTP. Mỗi cmdlet thực hiện một tác vụ đơn lẻ. Cmdlets có thể kết hợp với nhau để hoàn thành các chức năng tự động cao cấp hơn và các tác vụ quản trị các trung tâm dữ liệu. HÌnh bên dưới mô tả sự liên quan giữa PowerShell, UCS Director và hạ tầng mạng đang được quản lý.
UCS Director cung cấp REST API cho phép các ứng dụng gọi API để thao tác các dữ liệu được lưu giữ trong UCS Director. Các ứng dụng dùng HTTP hay HTTPS bằng REST API để thực hiện các tác vụ CRUD trên các tài nguyên UCS Director.
Chỉ với một cuộc gọi API, một nhà phát triển ứng dụng có thể thực thi các lưu đồ công việc và thay đổi các cấu hình của switches, adapter, các chính sách hay bất kỳ các thành phần phần cứng và phần mềm khác. API chấp nhận và trả về các thông điệp HTTP chứa các tài liệu ở định dạng JSON hay XML.
Để truy cập đến UCS Director REST API, chúng ta sẽ cần một tài khoản người dùng hợp lệ và một khóa truy cập API. UCS Director sử dụng khóa API để xác thực một cuộc gọi API. Khóa truy cập này là một mã truy cập duy nhất kết hợp với một tài khoản người dùng UCS Director. Để truy xuất khóa API của một người dùng cụ thể, đầu tiên bạn truy cập vào UCS Director với tài khoản người dùng cụ thể. Sau đó di chuyển chuột vào biểu tượng người dùng ở bên góc phải và chọn Edit My Profile. Trên trang Edit My Profile, chọn Show Advanced Settings và truy xuất khóa truy cập API từ vùng REST API Access Key. Cũng có một tùy chọn để tạo ra khóa truy cập nếu cần thiết. Trong phần user advanced setting là một tùy chọn để bật lên menu của developer. Bằng cách bật lên menu developer, chúng ta cũng cho phép truy cập đến trình duyệt REST API và tính năng Metadata. REST API browser xuất hiện bên dưới thanh Orchestration của Cisco UCS Director và cung cấp các thông tin API, tạo ra các code mới cho tất cả các loại API.
Tùy chọn Report Metadata xuất hiện trong tất cả các trang của giao diện UCS Director GUI; khi chọn lựa, nó trả về mã API mà GUI dùng để truy xuất các thông tin được hiển thị trong trang cụ thể đó. Mã này bao gồm một địa chỉ URL đầy đủ để dán vào trong trình duyệt để gửi yêu cầu đến UCS Director. Cả trình duyệt REST API và tính năng báo cáo Metadata là cực kỳ giá trị cho các nhà phát triển ứng dụng vì nó cung cấp các đoạn mã sẵn sàng sử dụng và các cuộc gọi API đến tất cả các tài nguyên của UCS Director. Hình bên dưới mô tả giao diện UCS Director REST API.
Mỗi REST API phải kết hợp với một HTTP header gọi là X-Cloupia-Request-Key, với các giá trị được gán đến khóa truy cập REST API truy xuất trước đây. REST API phải chứa một URL có định dạng sau:
https://Cisco_UCS_Director/app/api/rest?formatType=json&opName=operationName&op
Data=operationData
Trong đó
Cisco_UCS_Director: là địa chỉ IP hay hostname của UCS Director
formatType: Kiểu này có thể có định dạng JSON hay XML. Trong ví dụ này, định dạng là JSON.
opName: Đây là tên tác vụ API kết hợp với yêu cầu (ví dụ, userAPIGetMyLoginProfile
opData: Chứa các thông số hay các đối số của tác vụ. UCS Director dùng JSON để mã hóa cho các thông số. UCS Director dùng JSON để mã hóa các thông số. Nếu một hành động không yêu cầu bất kỳ thông số nào, tập hợp trống {} có thể được dùng. Khi xây dựng URL, ký tự escape phải được hiển thị cho phù hợp.
Kế tiếp, chúng ta hãy khảo sát UCS REST API bằng cách dùng lệnh curl để xây dựng API call. Để thử nghiệm, các bạn cũng có thể truy cập UCS Management cho mục đích học tập, https://developer.cisco.com/sandbox. Sandbox này chứa tất cả các cài đặt của UCS Director. UCS Director phiên bản 6.7 được sử dụng để tương tác với REST API. Tác vụ có tên userAPIGetMyLoginProfile được dùng để truy xuất profile của người dùng với các khóa truy cập được truyền trong request để nhận ra nhóm mà người dùng thuộc về. Lệnh curl cho tác vụ này sẽ có dạng như ví dụ bên dưới.
curl -k -L -X GET \
-g 'https://10.10.10.66/app/api/rest? formatType=json&opName=userAPIGetMyLoginProfile&op Data={}' \
-H 'X-Cloupia-Request-Key:8187C34017C3479089C66678F32775FE'
Thông số -g tắt cơ chế kiểm tra các dấu ngoặc nhọn lồng nhau. –k hay thông số -insecure cho phép curl xử lý và hoạt động ngay cả nếu máy hủ server sử dụng self-signed SSL. Thông số -L cho phép curl theo các điều hướng được gửi từ máy chủ. Địa chỉ URL theo các yêu cầu được thảo luận trước đây, dùng /app/api/rest để truy cập REST API và sau đó truyền
formatType, opName, và opData như các thông số. Phần header dùng cho xác thực là
XCloupia-Request-Key và chứa giá trị của khóa truy cập của người dùng có tên là admin, đang truy cập đến UCS Director ở địa chỉ 10.10.10.66.
Kết quả trả về của UCS Director được trình bày bên dưới. Tên của tác vụ chứa trong kết quả trả về, userAPIGetMyLoginProfile, serviceName chỉ ra tên của dịch vụ backend bên dưới (trong phần lớn trường hợp là InfraMgr), serviceResult chứa tập hợp các giá trị của JSON nếu yêu cầu là thành công. ServiceError chứa các thông điệp lỗi. Nếu yêu cầu là thành công, giá trị serviceError được gán bằng 0 và nếu yêu cầu là thất bại, serviceError sẽ chứa thông điệp lỗi.
{
"opName" : "userAPIGetMyLoginProfile",
"serviceName" : "InfraMgr",
"serviceResult" : {
"email" : null,
"groupName" : null,
"role" : "Admin",
"userId" : "admin",
"groupId" : 0,
"firstName" : null,
"lastName" : null
},
"serviceError" : null}
Như đã đề cập trước đây, các tác vụ và các lưu đồ công việc của UCS Director có thể có một số bất kỳ các thông số đầu vào và đầu ra. Để truy xuất các đầu vào của một lưu đồ công việc cụ thể, tác vụ
userAPIGetWorkflowInputs có thể được dùng với tên của lưu đồ công việc mong muốn trong trường param0. UCS Director có một số lượng lớn các lưu đồ công việc định nghĩa trước. Một trong số đó là
“VMware OVF Deployment,”, giúp triển khai các máy ảo mới dựa trên OVF. Lệnh curl trong ví dụ bên dưới chứa các cuộc gọi API để truy xuất tất cả các đầu vào của workflow này.
curl -k -L -X GET \
-g 'http://10.10.10.66/app/api/rest?
formatType=json&opName=userAPIGetWorkflowInput
s&opData=
{param0:%22VMware%20OVF%20Deployment%22}' \
-H 'X-Cloupia-Request-Key:
8187C34017C3479089C66678F32775FE'
Chú ý tên của workflow được truyền trong cuộc gọi API call với thông số param0 và VMware OVF Deployment được mã hóa, dùng các dấu nháy đơn và các khoảng trắng giữa các từ. Ví dụ bên dưới mô tả một phần của kết quả trả về. Kết quả chứa các trường tương tụ như trong ví dụ trước. Tên tác vụ opName được xác nhận là userAPIGetWorkflowInputs. Dịch vụ backend trả lời cho yêu cầu là InfraMgr, serviceError là null (chỉ ra rằng không có lỗi khi xử lý cuộc gọi API) và dịch vụ serviceResult chứa một danh sách được gọi là details, bao gồm tất cả các đầu vào và các thuộc tính của VMware OVF Deployment workflow.
{
"serviceResult":{
"details":[
{
"inputFieldValidator":
"VdcValidator",
"label":"vDC",
"type":"vDC",
"inputFieldType" : "embedded-lov",
"catalogType":null,
"isOptional":false,
"name":"input_0_vDC728",
"isMultiSelect":false,
"description":"",
"isAdminInput":false
},
{
"isAdminInput":false,
"description":"",
"label":"OVF URL",
"type":"gen_text_input",
"isMultiSelect":false,
"isOptional":false,
"inputFieldType":"text",
"catalogType":null,
"name":"input_1_OVF_URL465",
"inputFieldValidator" : null
},
...omitted output
]
},
"serviceName":"InfraMgr",
"opName":"userAPIGetWorkflowInputs",
"serviceError":null}
Tự động hóa cho phép mở rộng cần thiết, cải tiến tốc độ và độ chính xác cần thiết để tăng tính sáng tạo và trả lời nhanh chóng cho các yêu cầu kinh doanh trong môi trường trung tâm dữ liệu. UCS Director thay thế các cấu hình thủ công và các tiến trình cài đặt với khả năng sắp xếp để tối ưu và đơn giản hóa các tài nguyên trung tâm dữ liệu.
Nền tảng private cloud giúp triển khai công nghệ hạ tầng như một dịch vụ (IaaS) từ lớp lõi đến lớp biên của một trung tâm dữ liệu. Các qui trình tự động hóa có thể cấu hình, triển khai và quản lý các tài nguyên hạ tầng trên các tài nguyên tính toán, mạng, các tài nguyên lưu trữ và các giải pháp hạ tầng hội tụ, siêu hội tụ. UCS Director hỗ trợ các giải pháp hàng đầu trong lĩnh vực công nghệ hạ tầng hội tụ, bao gồm NetApp FlexFod và FlexPod Express, EMC VSPEX, EMC VPLEX và VCE Block. Nó cung cấp các giải pháp quản trị hội tụ và sắp đặt cho các hypervisor thật và ảo.
Một trang portal tự phục vụ, một danh mục các dịch vụ hiện đại và hơn 2500 các tác vụ cho phép truy cập theo yêu cầu đến các dịch vụ tích hợp trên các tài nguyên trung tâm dữ liệu. UCS Director cho phép các kỹ sư IT chuyên nghiệp và các đội phần mềm có thể yêu cầu và sắp xếp các dịch vụ hạ tầng theo yêu cầu.
UCS Director được hỗ trợ bởi một hệ sinh thái rộng lớn. Các phần cứng và các giải pháp của bên thứ ba có thể sử dụng southbound API và SDK đi kèm để phát triển phần tích hợp vào bên trong mô hình quản trị của UCS Director. Northbound API có thể được dùng bởi DevOps và các đội quản lý vận hành IT để tương tác với UCS Director và thực thi tất cả các tác vụ cung cấp bởi giải pháp theo cách lập trình và tự động.
UCS Director cung cấp các chức năng nhận dạng xuyên suốt các dòng lưu lượng và các giải pháp quản tị của hạ tầng mạng trung tâm dữ liệu. Từ quan điểm quản trị trung tâm dữ liệu, chúng ta có thể thực hiện một số tác vụ với UCS Director:
Tạo, nhân bản và triển khai các hồ sơ dịch vụ và các khuôn mẫu cho tất cả các máy chủ UCS và các ứng dụng tính toán. Quản lý, giám sát và báo cáo trên các thành phần trung tâm dữ liệu, chẳng hạn như UCS domain hay các thiết bị Cisco Nexus. Giám sát việc sử dụng, các khuynh hướng và dung lượng trên một hạ tầng mạng hội tự theo một nền tảng liên tục. Triển khai và thêm vào dung lượng cho các hạ tầng mạng hội tụ theo cách nhất quán, lặp lại.
UCS Director cũng cho phép tạo ra các lưu đồ công việc để tự động hóa các dịch vụ. Các lưu đồ này được phổ biến và có sẵn cho người dùng cuối trên các trang web portal. Khi đã xây dựng và kiểm tra xong, các lưu đồ thực hiện lặp lại giống nhau mỗi lần, bất chấp ai là người kích hoạt chúng.
Người quản trị trung tâm dữ liệu có thể chạy chúng, hoặc các cơ chế phân quyền có thể giúp các người dùng và khách hàng chạy các tiến trình này theo mô hình tự phục vụ. Từ quan điểm tự động hóa hạ tầng, một vài trường hợp ứng dụng UCS Director có thể giúp tự động hóa bao gồm các tác vụ tạo mới máy ảo, quản lý các chu kỳ thiết bị, các tài nguyên tính toán, các mạng và các tài nguyên lưu trữ. Cài đặt các máy chủ vật lý, bao gồm cài đặt hệ điều hành
UCS Director hỗ trợ ACI bằng cách cung cấp các qui trình công việc tự động giúp sắp xếp các cấu hình APIC và các tác vụ quản lý. Nó cũng hỗ trợ các mô hình nhiều khách hàng và khả năng để định nghĩa các contracts giữa các lớp container khác nhau. UCS Director có thể được quản lý dùng Cisco Intersigh. UCS Director là một ứng dụng 64bit sử dụng Open Virtualization Format (OVF) trên VMWare Vsphere và Virtual Hard Disk (VHD) cho Microsoft Hyper-V.
Kế tiếp, chúng ta hãy điểm qua một số khái niệm quan trọng cần thiết để hiểu làm thế nào UCS Director có thể sắp xếp các công việc. Đầu tiên một tác vụ (task) là một đơn vị nhỏ nhất của công việc, nó không thể được chia thành các hành động nhỏ hơn và có thể đại diện bởi một hành động đơn lẻ có đầu vào và đầu ra. UCS Director có một thư viện chứa hàng trăm các tác vụ định nghĩa trước, chẳng hạn như các lệnh SSH (thực thi một lệnh trong một phiên SSH), một tác vụ thu thập các thiết bị, tác vụ tạo mới máy ảo và nhiều tác vụ khác. Trong trường hợp không có một tác vụ định nghĩa trước nào là phù hợp, hệ thống cho phép chúng ta tạo mới các tác vụ tùy biến.
Khái niệm thứ hai là lưu đồ công việc (workflow). Một lưu đồ công việc là một chuỗi của các hành động được sắp xếp để tự động hóa các tác vụ phức tạp. Một tác vụ đơn giản nhất sẽ chứa chỉ một tác vụ nhưng một lưu đồ công việc sẽ chứa một số bất kỳ các tác vụ. Workflow là trái tim của UCS Director. Nó tự động các tiến trình ở bất kỳ mức độ phức tạp nào.
Các lưu đồ công việc được xây dựng bằng công cụ Workflow Designer, là một giao tiếp dạng kéo và thả. Trong công cụ Workflow Designer, các tác vụ được sắp xếp tuần tự và định nghĩa các đầu vào, đầu ra cho các tác vụ này. Các vòng lặp và các điều kiện có thể được thực thi, một yêu cầu dịch vụ được tạo ra. Các lưu đồ công việc có thể được định thời để thực thi sau và UCS Director lưu trữ các chi tiết của các yêu cầu dịch vụ đã hoàn thành. Trong công cụ Workflow Designer, các tác vụ được sắp xếp tuần tự và định nghĩa các đầu vào, đầu ra cho các tác vụ này. Các vòng lặp và các điều kiện có thể được hiện thực bằng cách dùng các tác vụ kiểm soát dòng. Một yêu cầu dịch vụ có thể có vài trạng thái, tùy thuộc vào các mức độ thực thi của nó: định thời, chạy, ngăn chặn, hoàn thành hay bị thất bại. Cuối cùng, các thư viện và các catalog là tập hợp của các tác vụ định nghĩa trước có thể được dùng như là các khối cho các tác vụ lưu đồ công việc cao cấp hơn.
Bây giờ chúng ta hãy khảo sát khả năng mở rộng và khả năng lập trình của UCS Director. UCS director SDK là một tập hợp của các công nghệ cho phép các nhà phát triển ứng dụng mở rộng khả năng của UCS, truy cập đến dữ liệu UCS Director, kích hoạt tính năng tự động hóa của UCS và sắp xếp các tác vụ cho bất kỳ ứng dụng nào.
UCS Director SDK bao gồm các thành phần Open Automation. Các công nghệ Scripting bao gồm UCS Director PowerShell API, các tác vụ tùy chọn trong UCS Director mô-đun và khả năng để viết các tác vụ tùy chọn dùng CloupiaScript. Đây là một bản JavaScript server-side.
UCS Director SDK có khả năng thực hiện các việc sau:
- Truy cập UCS Director thông qua lập trình bằng cách dùng UCSDirector REST API.
- Tùy biến UCS Director bằng cách tạo ra các tác vụ tùy chọn mới.
- Mở rộng UCS Director bằng cách dùng tính năng Director Open Automation để xây dựng các kết nối cho các thiết bị và các hệ thống thêm vào.
- UCS Director có mô-đun Open Automation cho phép các nhà phát triển nâng cao khả năng của UCS Director.
Open Automation có thể được dùng để thêm vào các mô-đun cho UCS Director. Một mô-đun là một điểm tiếp nhận mức cao nhất của UCS Director. Để thêm vào hay mở rộng chức năng của hệ thống, một mô-đun mới phải được phát triển và triển khai trên UCS Director. Một mô-đun phát triển dùng Open Automation cũng hoạt động giống như các tính năng có sẵn của UCS Director hay các mô-đun khác. Open Automation là một SDK dùng JAVA và các frame work chứa tất cả các tài nguyên cần thiết để phát triển một mô-đun mới.
Một vài ứng dụng mới của Open Automation là:
- Thêm vào khả năng để điều khiển một kiểu thiết bị mới với UCS Director.
- Thiết kế các menu tùy chọn để hiển thi các thiết bị mới hay các thành phần mới.
- Đưa các thiết bị mới vào phần danh sách thiết bị Inventory.
- Phát triển các báo cáo UCS Director và báo cáo các hành động.
- Phát triển các tác vụ cho phép các developer thực thi các tác vụ tùy biến trên các tài nguyên UCS.
Các tác vụ tùy biến được viết bằng CloudpiaScripts, một ngôn ngữ tựa như JavaScripts. Các tác vụ tùy biến có thể được dùng giống như các tác vụ nào khác, bao gồm các lưu đồ công việc sắp xếp cách thức các hệ thống làm việc. Các script bundle là một tập hợp của các tác vụ tùy biến bao gồm bên trong từng UCS Director và được dùng cho các ứng dụng cụ thể. Script bundle có thể được tải về và các tác vụ bên trong các bundle có thể được tải vào trong UCS Director. Mục đích chính của các tác vụ tùy biến là để mở rộng một loạt các tác vụ có sẵn để sử dụng trong các lưu đồ sắp đặt.
Các script mô-đun được dùng để tích hợp các JARs (Java Archive) của bên thứ ba và các thư viện của UCS Director để thêm vào các chức năng của UCS Director. Một vài hoạt động script mô-đun đã được định nghĩa trong UCS Director, chẳng hạn như tạo ra các chức năng điều khiển cao cấp để thu thập các thông tin đầu vào của người dùng cho các lưu đồ công việc và các ý nghĩa của các ngữ cảnh trong lưu đồ công việc. Chức năng này cho phép người quản trị kết hợp lưu đồ công việc với các hành động tùy biến trong một báo cáo đến UCS Director.
Các script mô-đun có thể được xuất ra và sử dụng trong các phiên bản khác của UCS Director. Các script mô-đun mặc dù có tên tương tự như script bundle, thật ra có vai trò rất khác biệt. Script bundle được đóng gói với một tập hợp của các tác vụ được phát hành chung với UCS Director. Các script mô-đun cho phép thêm các chức năng tùy biến vào UCS Director.
UCS Director PowerShell là một ứng dụng do Cisco phát triển cung cấp giao diện PowerShell đến UCS Director REST API. Chức năng console cung cấp tập hợp các PowerShell cmdlets được đóng gói trong một mô-đun để kích hoạt REST API thông qua HTTP. Mỗi cmdlet thực hiện một tác vụ đơn lẻ. Cmdlets có thể kết hợp với nhau để hoàn thành các chức năng tự động cao cấp hơn và các tác vụ quản trị các trung tâm dữ liệu. HÌnh bên dưới mô tả sự liên quan giữa PowerShell, UCS Director và hạ tầng mạng đang được quản lý.
UCS Director cung cấp REST API cho phép các ứng dụng gọi API để thao tác các dữ liệu được lưu giữ trong UCS Director. Các ứng dụng dùng HTTP hay HTTPS bằng REST API để thực hiện các tác vụ CRUD trên các tài nguyên UCS Director.
Chỉ với một cuộc gọi API, một nhà phát triển ứng dụng có thể thực thi các lưu đồ công việc và thay đổi các cấu hình của switches, adapter, các chính sách hay bất kỳ các thành phần phần cứng và phần mềm khác. API chấp nhận và trả về các thông điệp HTTP chứa các tài liệu ở định dạng JSON hay XML.
Để truy cập đến UCS Director REST API, chúng ta sẽ cần một tài khoản người dùng hợp lệ và một khóa truy cập API. UCS Director sử dụng khóa API để xác thực một cuộc gọi API. Khóa truy cập này là một mã truy cập duy nhất kết hợp với một tài khoản người dùng UCS Director. Để truy xuất khóa API của một người dùng cụ thể, đầu tiên bạn truy cập vào UCS Director với tài khoản người dùng cụ thể. Sau đó di chuyển chuột vào biểu tượng người dùng ở bên góc phải và chọn Edit My Profile. Trên trang Edit My Profile, chọn Show Advanced Settings và truy xuất khóa truy cập API từ vùng REST API Access Key. Cũng có một tùy chọn để tạo ra khóa truy cập nếu cần thiết. Trong phần user advanced setting là một tùy chọn để bật lên menu của developer. Bằng cách bật lên menu developer, chúng ta cũng cho phép truy cập đến trình duyệt REST API và tính năng Metadata. REST API browser xuất hiện bên dưới thanh Orchestration của Cisco UCS Director và cung cấp các thông tin API, tạo ra các code mới cho tất cả các loại API.
Tùy chọn Report Metadata xuất hiện trong tất cả các trang của giao diện UCS Director GUI; khi chọn lựa, nó trả về mã API mà GUI dùng để truy xuất các thông tin được hiển thị trong trang cụ thể đó. Mã này bao gồm một địa chỉ URL đầy đủ để dán vào trong trình duyệt để gửi yêu cầu đến UCS Director. Cả trình duyệt REST API và tính năng báo cáo Metadata là cực kỳ giá trị cho các nhà phát triển ứng dụng vì nó cung cấp các đoạn mã sẵn sàng sử dụng và các cuộc gọi API đến tất cả các tài nguyên của UCS Director. Hình bên dưới mô tả giao diện UCS Director REST API.
Mỗi REST API phải kết hợp với một HTTP header gọi là X-Cloupia-Request-Key, với các giá trị được gán đến khóa truy cập REST API truy xuất trước đây. REST API phải chứa một URL có định dạng sau:
https://Cisco_UCS_Director/app/api/rest?formatType=json&opName=operationName&op
Data=operationData
Trong đó
Cisco_UCS_Director: là địa chỉ IP hay hostname của UCS Director
formatType: Kiểu này có thể có định dạng JSON hay XML. Trong ví dụ này, định dạng là JSON.
opName: Đây là tên tác vụ API kết hợp với yêu cầu (ví dụ, userAPIGetMyLoginProfile
opData: Chứa các thông số hay các đối số của tác vụ. UCS Director dùng JSON để mã hóa cho các thông số. UCS Director dùng JSON để mã hóa các thông số. Nếu một hành động không yêu cầu bất kỳ thông số nào, tập hợp trống {} có thể được dùng. Khi xây dựng URL, ký tự escape phải được hiển thị cho phù hợp.
Kế tiếp, chúng ta hãy khảo sát UCS REST API bằng cách dùng lệnh curl để xây dựng API call. Để thử nghiệm, các bạn cũng có thể truy cập UCS Management cho mục đích học tập, https://developer.cisco.com/sandbox. Sandbox này chứa tất cả các cài đặt của UCS Director. UCS Director phiên bản 6.7 được sử dụng để tương tác với REST API. Tác vụ có tên userAPIGetMyLoginProfile được dùng để truy xuất profile của người dùng với các khóa truy cập được truyền trong request để nhận ra nhóm mà người dùng thuộc về. Lệnh curl cho tác vụ này sẽ có dạng như ví dụ bên dưới.
curl -k -L -X GET \
-g 'https://10.10.10.66/app/api/rest? formatType=json&opName=userAPIGetMyLoginProfile&op Data={}' \
-H 'X-Cloupia-Request-Key:8187C34017C3479089C66678F32775FE'
Thông số -g tắt cơ chế kiểm tra các dấu ngoặc nhọn lồng nhau. –k hay thông số -insecure cho phép curl xử lý và hoạt động ngay cả nếu máy hủ server sử dụng self-signed SSL. Thông số -L cho phép curl theo các điều hướng được gửi từ máy chủ. Địa chỉ URL theo các yêu cầu được thảo luận trước đây, dùng /app/api/rest để truy cập REST API và sau đó truyền
formatType, opName, và opData như các thông số. Phần header dùng cho xác thực là
XCloupia-Request-Key và chứa giá trị của khóa truy cập của người dùng có tên là admin, đang truy cập đến UCS Director ở địa chỉ 10.10.10.66.
Kết quả trả về của UCS Director được trình bày bên dưới. Tên của tác vụ chứa trong kết quả trả về, userAPIGetMyLoginProfile, serviceName chỉ ra tên của dịch vụ backend bên dưới (trong phần lớn trường hợp là InfraMgr), serviceResult chứa tập hợp các giá trị của JSON nếu yêu cầu là thành công. ServiceError chứa các thông điệp lỗi. Nếu yêu cầu là thành công, giá trị serviceError được gán bằng 0 và nếu yêu cầu là thất bại, serviceError sẽ chứa thông điệp lỗi.
{
"opName" : "userAPIGetMyLoginProfile",
"serviceName" : "InfraMgr",
"serviceResult" : {
"email" : null,
"groupName" : null,
"role" : "Admin",
"userId" : "admin",
"groupId" : 0,
"firstName" : null,
"lastName" : null
},
"serviceError" : null}
Như đã đề cập trước đây, các tác vụ và các lưu đồ công việc của UCS Director có thể có một số bất kỳ các thông số đầu vào và đầu ra. Để truy xuất các đầu vào của một lưu đồ công việc cụ thể, tác vụ
userAPIGetWorkflowInputs có thể được dùng với tên của lưu đồ công việc mong muốn trong trường param0. UCS Director có một số lượng lớn các lưu đồ công việc định nghĩa trước. Một trong số đó là
“VMware OVF Deployment,”, giúp triển khai các máy ảo mới dựa trên OVF. Lệnh curl trong ví dụ bên dưới chứa các cuộc gọi API để truy xuất tất cả các đầu vào của workflow này.
curl -k -L -X GET \
-g 'http://10.10.10.66/app/api/rest?
formatType=json&opName=userAPIGetWorkflowInput
s&opData=
{param0:%22VMware%20OVF%20Deployment%22}' \
-H 'X-Cloupia-Request-Key:
8187C34017C3479089C66678F32775FE'
Chú ý tên của workflow được truyền trong cuộc gọi API call với thông số param0 và VMware OVF Deployment được mã hóa, dùng các dấu nháy đơn và các khoảng trắng giữa các từ. Ví dụ bên dưới mô tả một phần của kết quả trả về. Kết quả chứa các trường tương tụ như trong ví dụ trước. Tên tác vụ opName được xác nhận là userAPIGetWorkflowInputs. Dịch vụ backend trả lời cho yêu cầu là InfraMgr, serviceError là null (chỉ ra rằng không có lỗi khi xử lý cuộc gọi API) và dịch vụ serviceResult chứa một danh sách được gọi là details, bao gồm tất cả các đầu vào và các thuộc tính của VMware OVF Deployment workflow.
{
"serviceResult":{
"details":[
{
"inputFieldValidator":
"VdcValidator",
"label":"vDC",
"type":"vDC",
"inputFieldType" : "embedded-lov",
"catalogType":null,
"isOptional":false,
"name":"input_0_vDC728",
"isMultiSelect":false,
"description":"",
"isAdminInput":false
},
{
"isAdminInput":false,
"description":"",
"label":"OVF URL",
"type":"gen_text_input",
"isMultiSelect":false,
"isOptional":false,
"inputFieldType":"text",
"catalogType":null,
"name":"input_1_OVF_URL465",
"inputFieldValidator" : null
},
...omitted output
]
},
"serviceName":"InfraMgr",
"opName":"userAPIGetWorkflowInputs",
"serviceError":null}