Tweet
Ucs manager
UCS MANAGER
UCS bao gồm phần lớn các sản phẩm máy chủ của Cisco. Sản phẩm UCS đầu tiên ra mắt năm 2009 và nó nhanh chóng thiết lập vị thế dẫn đầu trong dòng thị trường máy chủ và trung tâm dữ liệu. UCS cung cấp một giải pháp máy chủ hợp nhất kết hợp mạng, khả năng lưu trữ và tính toán trong một hệ thống duy nhất. Trong khi giải pháp UCS ban đầu sử dụng thiết bị lưu trữ mạng NAS hoặc SAN để giải quyết yêu cầu cho các lưu trữ dữ liệu lớn, Cisco HyperFlex và các dòng máy chủ siêu hội tụ hyperconverged server và các dung lượng lưu trữ lớn đã tích hợp trong giải pháp UCS.
Các máy chủ dạng phiến B-series, C-series rack servers, S-series, UCS mini và HyperFlex có thể được quản lý thông qua một giao tiếp duy nhất UCS Manager. UCS Manager cung cấp một giải pháp hợp nhất, tích hợp quản trị của các phần cứng và phần mềm của UCS. UCS Manager chạy trên một cặp của thiết bị phần cứng gọi là fabric interconnects. Hai fabric kết nối với nhau để hình thành một cluster dạng active/standby, trong đó cung cấp cơ chế HA. Hạ tầng UCS đang được quản lý bởi UCS Manager tạo nên một UCS fabric có thể bao gồm đến 160 máy chủ. Hệ thống có thể mở rộng lên đến hàng ngàn máy chủ bằng cách tích hợp UCS Manager với UCS Central trong một môi trường đa dịch vụ.
UCS Manager tham gia vào toàn bộ dòng đời sống của một máy chủ, bao gồm cài đặt máy chủ, khám phá thiết bị, quản lý thiết bị, cấu hình, điều tra, giám sát, phát hiện lỗi, thu thập các thông tin thống kê. Tất cả các hạ tầng mạng đang được quản lý bởi UCS Manager kết nối trực tiếp đến fabric interconnect hay kết nối thông qua fabric extenders. Các fabric extender có chức năng cung cấp các khả năng thêm vào trong việc kết nối các máy chủ vào fabric interconnect. Các thiết bị này không tốn nhiều công sức quản lý, chi phí thấp, tiêu hao năng lượng thấp và loại bỏ nhu cầu sử dụng các switch Ethernet and Fibre Channel switches.
Hình bên dưới mô tả các thành phần này kết nối với nhau:
Tất cả các máy chủ UCS hỗ trợ công nghệ SingleConnect. Cisco SingleConnect là một công nghệ hỗ trợ tất cả các loại lưu lượng từ các máy chủ (LAN, SAN, quản lý…) trên một kết nối vật lý duy nhất. Những gì công nghệ này giúp tiết kiệm chỉ là một phần của cấu trúc cáp đơn giản hóa. UCS Manager cung cấp giao diện HTML5 (GUI), giao diện CLI và một API đầy đủ. Tất cả các chức năng UCS và các đối tượng quản lý đều có sẵn thông qua UCS API. Các nhà phát triển có thể tận dụng các API mở rộng này và có thể nâng cấp nền tảng UCS theo các yêu cầu duy nhất. Các công cụ và các phần mềm tích hợp với các giải pháp từ các bên thứ ba như VMWare, Microsoft và Splunk đều được phổ biến rộng rãi.
Trong phần sau của chương, chúng ta sẽ thấy các công cụ UCS PowerTool for UCS Manager và Python SDK có thể được dùng để tự động hóa và lập trình quản lý UCS Manager. Với UCS Manager, các máy chủ trung tâm dữ liệu có thể được quản lý dùng IaC (Infrastructure As Code). Điều này là có thể thông qua các phát kiến bao gồm bên trong giải pháp UCS: hồ sơ dịch vụ (service profile). Hồ sơ dịch vụ là một cấu trúc luận lý bên trong UCS Manager chứa cấu hình đầy đủ của một máy chủ vật lý. Tất cả các thành phần của một cấu hình máy chủ, bao gồm các mức RAID, cài đặt BIOS, các phiên bản firmware, cài đặt adapter, cài đặt mạng và các thiết bị lưu trữ và các kết nối đến trung tâm dữ liệu đều được bao gồm trong hồ sơ dịch vụ. Khi một hồ sơ dịch vụ được kết hợp với một máy chủ, UCS Manager tự động cấu hình máy chủ, các adapter, fabric extenders và fabric interconnect để đúng với mô tả được chỉ ra trong hồ sơ dịch vụ. Với các hồ sơ dịch vụ, hạ tầng có thể được cấu hình trong vài phút thay vì vài ngày. Bạn có thể cấu hình sẵn các máy chủ và có các cấu hình này sẵn sàng trước khi các máy chủ kết nối vào mạng. Khi các máy chủ đã online và tìm thấy bởi UCS Manager, các hồ sơ dịch vụ có thể tự động triển khai đến các máy chủ.
Giao tiếp lập trình trong UCS Manager là XML API. XML API của UCS Manager chấp nhận các tài liệu XML trên các kết nối HTTP hay HTTPS. Cũng giống như ACI, các thông tin cấu hình và thông tin trạng thái của UCS được lưu trong một cấu trúc cây có thứ bậc được gọi là cây thông tin quản lý (Management Information Tree- MIT). Cây MIT chứa tất cả các đối tượng được quản lý trong một hệ thống UCS, có thể truy cập thông qua XML API. Bất kỳ ngôn ngữ lập trình nào cũng có thể được dùng để tạo ra các tài liệu XML, bao gồm các phương thức API. Một hoặc nhiều các đối tượng có thể thay đổi chỉ với một cuộc gọi API. Khi có nhiều đối tượng đang được cấu hình, các hoạt động API sẽ dừng nếu có bất kỳ một đối tượng nào không thể được cấu hình và hệ thống có thể quay trở lại trạng thái trước khi có sự thay đổi. Các hoạt động API làm việc theo phiên và được thực thi trên từng mô hình dữ liệu, tượng trưng cho toàn bộ hệ thống.
UCS Manager chịu trách nhiệm quản lý tất cả các giao tiếp đầu cuối, làm cho UCS Manager là nơi chứa thông tin chính xác nhất (single source of truth). UCS Manager giải phóng các nhà phát triển phần mềm ra khỏi việc quản lý các cấu hình của các thành phần riêng lẻ, tách biệt. Tất cả các yêu cầu XML là bất đối xứng (asynchronous) và kết thúc trong UCS Manager.
Tất cả các thành phần vật lý và luận lý tạo thành UCS được mô tả trong một cây thông tin quản lý (Management Information Tree - MIT), hay còn được gọi là Management Information Model (MIM). Từng nốt trong một cây được gọi là các đối tượng được quản lý (Managed Object - MO), là một nhóm của các đối tượng chứa các thông tin quản trị và các trạng thái hoạt động. Ở đỉnh của cấu trúc phân cấp này là đối tượng sys, chứa tất cả các nốt cha và nốt con trong cấu trúc cây. Từng đối tượng trong UCS có một tên duy nhất mô tả đối tượng và vị trí của nó trong cây. Mô hình thông tin này thường được lưu trữ trung tâm và quản lý bởi một tiến trình chạy trên các kết nối fabric interconnect được gọi là Data Management Engine (DME). Khi một thay đổi quản trị được kích hoạt đến một thành phần UCS, DMS đầu tiên sẽ áp dụng các thay đổi đến các mô hình thông tin, sau đó áp đặt các thay đổi tới các đầu cuối được quản trị. Giải pháp này được gọi là model-driven framework.
Một đối tượng quản trị cụ thể trong cây MIT có thể được nhận ra bởi tên distinguished name (DN) hoặc bởi tên liên quan của nó (relative name RN). DN xác định chính xác đối tượng được quản lý trong đó API call hoạt động và bao gồm một loạt các tên liên quan:
DN = {RN}/{RN}/{RN}/{RN}...
Một tên tương đối giúp xác định một đối tượng trong ngữ cảnh của đối tượng mức cha của đối tượng đang khảo sát. Mô hình UCS Manager XML API bao gồm các thành phần lập trình sau:
Lớp: Lớp định nghĩa các phương thức và các trạng thái của đối tượng bên trong cây MIT.
Phương thức: Định nghĩa các hành động mà API thực thi trên một hoặc nhiều đối tượng.
Kiểu: Các kiểu là các thuộc tính đối tượng thực hiện chuyển đổi các giá trị sang các trạng thái của đối tượng.
Có vài kiểu phương thức được hỗ trợ bởi XML API:
Phương thức xác thực: các phương thức này bao gồm các thành phần sau
aaaLogin: Phương thức login.
aaaRefresh: Làm mới các cookie dùng cho xác thực.
aaaLogout: Thoát khỏi phiên và ngừng sử dụng cookie xác thực tương ứng.
Phương thức truy vấn: Các phương thức này bao gồm các thành phần sau, được dùng để thu thập các trạng thái cấu hình của một đối tượng:
configResolveDn: Truy cập một đối tượng bởi DN.
configResolveClass: Truy xuất các đối tượng của một lớp cho trước.
configResolveParent: Truy xuất đối tượng cha của một đối tượng.
Phương thức cấu hình: Các phương thức này bao gồm các thành phần sau, được dùng để thay đổi cấu hình tới các đối tượng.
configConfMo: Ảnh hưởng đến MO.
configConfMos: Ảnh hưởng nhiều cây con.
Vì các phương thức truy vấn ở dạng XML API có thể trả về một số lượng lớn các dữ liệu, các bộ lọc có thể được hỗ trợ để giới hạn các kết quả này. Có bốn kiểu bộ lọc:
Lọc đơn giản: Các bộ lọc dạng đúng/sai này giới hạn các tập hợp kết quả của những đối tượng với các giá trị Đúng hay Sai.
Lọc theo các thuộc tính: Các bộ lọc này sử dụng các giá trị của các thuộc tính đối tượng như là các tiêu chí bao gồm trong một tập hợp kết quả (ví dụ equal filter, not equal filter, greater than filter).
Lọc tổng hợp: các bộ lọc này bao gồm hai hay nhiều các bộ lọc thành phần (ví dụ như AND filter, OR filter).
Bộ lọc thay đổi: Các bộ lọc này thay đổi kết quả của một bộ lọc container. Hiện tại chỉ có bộ lọc NOT là được hỗ trợ. Bộ lọc này phủ định kết quả của một container filter.
Các ứng dụng bên ngoài có thể thu thập thông tin thay đổi trạng thái của UCS bằng cách định kỳ truy vấn hay bằng webhook. Đăng ký nhận các biến cố xảy ra với hệ thống thông qua API là phương pháp được mong muốn hơn. Truy vấn polling thường sử dụng nhiều tài nguyên và nên được dùng trong những tình huống hạn chế.
UCS Manager có kèm theo một trình duyệt Visore giúp xem các đối tượng. Visore có thể được truy cập ở địa chỉ https://<UCS-Manager-IP>/visore.html. Bên dưới là giao diện trang web.
Toàn bộ cây thông tin quản trị MIT có thể được khám phá bằng công cụ Visore này. Ngoài ra các truy vấn cho một DN cụ thể cũng có thể chạy từ giao diện. Các tài nguyên liên quan đến UCS Manager có thể được tìm thấy ở địa chỉ https://developer.cisco.com/site/ucs-dev-center/.
Bước kế tiếp, hãy khảo sát các UCS XML API. Toàn bộ tài liệu đầy đủ của UCS cho các phiên bản khác nhau có thể được tìm thấy ở địa chỉ https://developer.cisco.com/site/ucs...ef-api-picker/. Ở site này, bạn có thể tìm tất cả các đối tượng đang quản lý, tất cả các phương thức, tất cả các kiểu, các báo lỗi và các luật FSM, và các tài liệu.
Để các nhà quản trị của các trung tâm dữ liệu có thể trở nên quen thuộc với hệ thống UCS, Cisco có phát hành một phần mềm mô phỏng. Phần mềm mô phỏng là một ứng dụng UCS được chạy bên trong một máy ảo VM. VM bao gồm các phần mềm mô phỏng các giao tiếp phần cứng cho hệ thống UCS. Phần mềm mô phỏng có thể tạo và thử nghiệm các cấu hình UCS hoặc để nhân bản một môi trường UCS cho mục đích khắc phục sự cố troubleshooting hay phát triển phần mềm. Phần mềm mô phỏng UCS phân phối dưới dạng file OVA và có thể chạy gần như trên môi trường ảo nào. Tài liệu đầy đủ cho UCS Manager cũng có trong phần mềm mô phỏng này.
Trong ví dụ bên dưới, chúng ta sẽ thử đăng ký dịch vụ sandbox. Sandbox là một dịch vụ lab online miễn phí của Cisco để giúp cộng đồng thử nghiệm các bài lab. Loại sandbox này có thể được đăng ký trước lên đến bảy ngày và chỉ dành cho những người đã đăng ký sử dụng. Có một UCS Manager Sandbox có thể được dùng để khảo sát XML API, ở địa chỉ https://developer.cisco.com/sandbox.
Sandbox này sử dụng phần mềm giả lập UCS Platform Emulator phiên bản 3.2(2.5). Ở thời điểm này, để xác thực và nhận một authentication cookie, chúng ta có thể dùng lệnh curl như ở bên dưới.
curl -k -X POST https://10.10.20.110/nuova \
-H 'Content-Type: application/xml' \
-d '<aaaLogin inName="ucspe" inPassword="ucspe"></aaaLogin>'
Địa chỉ IP của UCS Manager là 10.10.20.110, tài nguyên XML API ở địa chỉ /nuova và phương thức xác thực được dùng là aaaLogin. Tên người dùng và mật khẩu được truyền trong một tài liệu XML với biến là inName và inPassword. Trong cả hai trường hợp là ucspe. Phần header Content-Type chỉ ra kiểu dữ liệu mà cuộc gọi POST sẽ dùng để gửi đến XML API (trong trường hợp này dĩ nhiên là XML). Kết quả trả về phải tương tự như sau:
<aaaLogin cookie="" response="yes"
outCookie="1573019916/7c901636-c461-487e-bbd0-c74cd68c27be" outRefreshPeriod="600"
outPriv="aaa,admin,ext-lan-config,ext-lan-policy,ext-lan-qos,ext-lan-security,ext-san-config,ext-san-policy,ext-sansecurity,fault,operations,pod-config,pod-policy,pod-qos,podsecurity,read-only" outDomains="org-root" outChannel="noencssl"
outEvtChannel="noencssl" outSessionId="" outVersion="3.2(2.5)"
outName="" />
aaaLogin chỉ ra phương thức được dùng để login, giá trị “yes” xác nhận rằng đây là một kết quả trả về, outCookie cung cấp cookie cho phiên, outRefreshPeriod chỉ ra các chu kỳ làm mới cookie (mặc định là 600 giây), và giá trị outPriv chỉ ra mức phân quyền của tài khoản đăng nhập. Bước kế tiếp hãy truy cập danh sách của tất cả các đối tượng là một phần của lớp tính toán đang được quản lý bởi UCS Manager. Để hoàn thành việc này, chúng ta có thể dùng phương pháp configFindDnsByClassID. Phương thức này tìm ra các tên khác nhau và trả kết quả về bởi class ID.
Lệnh curl phải có dạng như sau:
curl -k -X POST https://10.10.20.110/nuova \
-H 'Content-Type: application/xml' \
-d '<configFindDnsByClassId
classId="computeItem"
cookie="1573019916/7c901636-c461-487e-bbd0-c74cd68c27be"
/>'
Đầu cuối XML API ở địa chỉ https://10.10.20.110/nuova, phần Content-Type header application/xml cũng vẫn như cũ. Dữ liệu XML đang được gửi đến UCS thì khác với ví dụ trước. Đầu tiên, phương tức configFindDnsbyClassID được chỉ ra và sau đó hai biến chủ chốt cho classID và cookie được truyền. ClassId chỉ ra lớp đối tượng, trong trường hợp này là computerItem và cookie đang được sử dụng giá trị đã có trước đây.
Kết quả trả về trong trường hợp này chứa một danh sách đầy đủ các thành phần đang được dùng bởi địa chỉ 10.10.20.110 của UCS Manager.
<configFindDnsByClassId
cookie="1573019916/7c901636-c461-487e-bbd0-
c74cd68c27be"
response="yes" classId="computeItem">
<outDns>
<dn value="sys/chassis-
4/blade-8"/>
<dn value="sys/chassis-
5/blade-8"/>
<dn value="sys/chassis-
6/blade-8"/>
<dn value="sys/chassis-
6/blade-1"/>
<dn value="sys/chassis-
3/blade-1"/>
... omitted output
<dn value="sys/rack-unit-9"/>
<dn value="sys/rack-unit-8"/>
<dn value="sys/rack-unit-7"/>
<dn value="sys/rack-unit-6"/>
<dn value="sys/rack-unit-5"/>
<dn value="sys/rack-unit-4"/>
<dn value="sys/rack-unit-3"/>
<dn value="sys/rack-unit-2"/>
<dn value="sys/rack-unit-1"/>
</outDns>
</configFindDnsByClassId>
Tiếp theo trong phần khảo sát UCS Manager XMP API, chúng ta hãy truy cập thông tin về một đối tượng cụ thể. Phương thức dùng để truy xuất một đối tượng riêng lẻ cho một DN cụ thể là configResolveDn.
Lệnh curl cho yêu cầu này có dạng
curl -k -X POST https://10.10.20.110/nuova \
-H 'Content-Type: application/xml' \
-d '<configResolveDn
cookie="1573019916/7c901636-c461-487e-bbd0-
c74cd68c27be"
dn="sys/chassis-4/blade-8" />'
Cũng giống như trong lần gọi trước, đầu cuối API và header Content-Type có cùng giá trị. Dữ liệu XML được gởi bên trong phần request chứa phương thức configResolveDn, các authentication cookie và DN mà chúng ta đang cần truy xuất thông tin. Trong trường hợp này, DN là blade server số 8 nằm trong chassis thứ tư. sys/chassis-4/blade-8.
Kết quả trả về được hiển thị bên dưới:
<configResolveDn dn="sys/chassis-4/blade-8"
cookie="1573019916/7c901636-c461-487e-bbd0-
c74cd68c27be" response="yes">
<outConfig>
<computeBlade
adminPower="policy" adminState="in-service"
assetTag=""
assignedToDn=""
association="none"
availability="available"
availableMemory="49152"
chassisId="4"
checkPoint="discovered"
connPath="A,B" connStatus="A,B" descr=""
discovery="complete"
discoveryStatus=""
dn="sys/chassis-4/blade-8" fltAggr="0"
fsmDescr=""
fsmFlags=""
fsmPrev="DiscoverSuccess"
fsmProgr="100" fsmRmtInvErrCode="none"
fsmRmtInvErrDescr=""
fsmRmtInvRslt=""
fsmStageDescr="" fsmStamp="2019-11-
06T04:02:03.896"
fsmStatus="nop"
fsmTry="0" intId="64508"
kmipFault="no" kmipFaultDescription=""
lc="undiscovered"
lcTs="1970-01-01T00:00:00.000"
localId="" lowVoltageMemory="not-applicable"
managingInst="A"
memorySpeed="not-applicable" mfgTime="notapplicable"
model="UCSBB200-
M4" name=""
numOf40GAdaptorsWithOldFw="0"
numOf40GAdaptorsWithUnknownFw="0"
numOfAdaptors="1"
numOfCores="8" numOfCoresEnabled="8"
numOfCpus="2"
numOfEthHostIfs="0"
numOfFcHostIfs="0" numOfThreads="16"
operPower="off"
operPwrTransSrc="unknown"
operQualifier="" operSolutionStackType="none"
operState="unassociated"
operability="operable"
originalUuid="1b4e28ba-2fa1-11d2-0408-b9a761bde3fb"
partNumber="" policyLevel="0"
policyOwner="local"
presence="equipped"
revision="0" scaledMode="none" serial="SRV137"
serverId="4/8"
slotId="8" totalMemory="49152"
usrLbl=""
uuid="1b4e28ba-2fa1-11d2-0408-
b9a761bde3fb"
vendor="Cisco Systems Inc"
vid=""/>
</outConfig>
</configResolveDn>
Mặc dù tương tác với UCS Manager XML API theo cách này vẫn tạm ổn, bạn sẽ thấy cách này nhanh chóng trở nên cồng kềnh. Cách được mong muốn hơn khi làm việc với XML API là thông qua công cụ UCS PowerTool hay UCS Python SDK. Cisco UCS PowerTool là một mô-đun giúp tự động hóa tất cả các phương diện của UCS Manager. PowerTool cmdlets làm việc trên UCS MIT. Cmdlets có thể được dùng để đọc, tạo mới, thay đổi và xóa các đối tượng trong cây Thông tin Quản lý MIT. UCS Power Tool cho phép dễ dàng tích hợp với các công cụ và tiến trình quản lý khác.
Bộ công cụ PowerTool có thể tải về từ địa chỉ https://community.cisco.com/t5/cisco...r/ta-p/3985798.
UCS Python SDK là một mô-đun Python giúp tự động hóa tất cả các khía cạnh quản lý UCS, bao gồm các máy chủ, mạng, vùng thiết bị lưu trữ và quản lý các hypervisor. UCS Python SDK làm việc trên UCS Manager MIT, thực hiện các tác vụ tạo mới, đọc, thay đổi hoặc xóa các đối tượng trong cây. Cả Python 2.7 và Python 3.5 đều được hỗ trợ. UCS Python mô-đun cho UCS Manager được gọi là ucsmsdk và có thể được cài đặt dùng pip với câu lệnh pip install ucsmsdk.
Phiên bản hiện tại của ucsmsdk của mô-đun là 0.9.8. UCS Python SDK cung cấp một công cụ được gọi là convert_to_ucs_python cho phép người quản trị và nhà phát triển các tùy chọn để lưu lại tất cả các tương tác với UCS Manager GUI và lưu nó trong một file XML. Chạy file XML này bằng công cụ convert_to_ucs_python tự động tạo ra các hành động được thực thi trong giao diện GUI. Sử dụng tiến trình này, các nỗ lực tự động hóa các trung tâm dữ liệu có thể được tăng tốc và các tác vụ đơn giản như tạo mới VLAN hay các tác vụ phức tạp chẳng hạn như cấu hình các mẫu chính sách dịch vụ mới có thể được tự động hóa trong vài giây.
Kế tiếp, hãy khảo sát UCS Python SDK và hãy xem làm thế nào để kết nối đến UCS Manager để truy xuất danh sách của tất cả các server blade trong hệ thống và cách thức truy xuất các thông tin trong các dữ liệu trả về. Đoạn chương trình mẫu Python được xây dựng từ
Python 3.7.4, sử dụng phiên bản 0.9.8 của mô-đun ucsmsdk.
Đầu tiên, lớp UcsHandle được nạp vào chương trình. Một phiên bản của lớp này được dùng để kết nối đến UCS Manager. Địa chỉ UCS Manager, tên người dùng và mật khẩu được truyền trong các thông số đến phiên bản của lớp UcsHandle, tạo thành một phiên bảngọi là HANDLE. Có vài phương thức có sẵn với lớp UcsHandle. Trong đoạn mã này, chỉ có ba loại phương thức được dùng.
HANDLE.login(): Phương thức này được dùng để truy cập vào UCS Manager.
HANDLE.query_classid(): Phương thức này được dùng để truy vấn cây MIT về các đối tượng với một classID cụ thể.
HANDLE.logout(): Phương thức này được dùng để logout ra khỏi UCS Manager.
Biến BLADES chứa một tự điển của tất cả các máy chủ blade đang được quản lý bởi phiên bản
UCS Manager ở địa chỉ 10.10.20.110. Bên trong vòng lặp for, các thông tin liên quan đến DN, số Serial Number, trạng thái quản trị, số model và tổng số bộ nhớ cho từng máy chủ được truy xuất và hiển thị ra màn hình.
Đoạn mã Python dùng UCS Manager SDK giúp hoàn thành tất cả các tác vụ này được mô tả trong hình bên dưới.
#! /usr/bin/env python
from ucsmsdk.ucshandle import UcsHandle
HANDLE = UcsHandle("10.10.20.110", "ucspe","ucspe")
# Login into Cisco UCS Manager
HANDLE.login()
# Retrieve all the compute blades
BLADES = HANDLE.query_classid("ComputeBlade")
print('{0:23s}{1:8s}{2:12s}{3:14s}
{4:6s}'.format(
"DN",
"SERIAL",
"ADMIN STATE",
"MODEL",
"TOTAL MEMORY"))
print('-'*70)
# Extract DN, serial number, admin state,
# model, and total memory for each blade
for BLADE in BLADES:
print('{0:23s}{1:8s}{2:12s}{3:14s}
{4:6s}'.format(
BLADE.dn,
BLADE.serial,
BLADE.admin_state,
BLADE.model,
BLADE.total_memory))
HANDLE.logout()
Kết quả của chạy đoạn scrip này được trình bày bên dưới:
UCS bao gồm phần lớn các sản phẩm máy chủ của Cisco. Sản phẩm UCS đầu tiên ra mắt năm 2009 và nó nhanh chóng thiết lập vị thế dẫn đầu trong dòng thị trường máy chủ và trung tâm dữ liệu. UCS cung cấp một giải pháp máy chủ hợp nhất kết hợp mạng, khả năng lưu trữ và tính toán trong một hệ thống duy nhất. Trong khi giải pháp UCS ban đầu sử dụng thiết bị lưu trữ mạng NAS hoặc SAN để giải quyết yêu cầu cho các lưu trữ dữ liệu lớn, Cisco HyperFlex và các dòng máy chủ siêu hội tụ hyperconverged server và các dung lượng lưu trữ lớn đã tích hợp trong giải pháp UCS.
Các máy chủ dạng phiến B-series, C-series rack servers, S-series, UCS mini và HyperFlex có thể được quản lý thông qua một giao tiếp duy nhất UCS Manager. UCS Manager cung cấp một giải pháp hợp nhất, tích hợp quản trị của các phần cứng và phần mềm của UCS. UCS Manager chạy trên một cặp của thiết bị phần cứng gọi là fabric interconnects. Hai fabric kết nối với nhau để hình thành một cluster dạng active/standby, trong đó cung cấp cơ chế HA. Hạ tầng UCS đang được quản lý bởi UCS Manager tạo nên một UCS fabric có thể bao gồm đến 160 máy chủ. Hệ thống có thể mở rộng lên đến hàng ngàn máy chủ bằng cách tích hợp UCS Manager với UCS Central trong một môi trường đa dịch vụ.
UCS Manager tham gia vào toàn bộ dòng đời sống của một máy chủ, bao gồm cài đặt máy chủ, khám phá thiết bị, quản lý thiết bị, cấu hình, điều tra, giám sát, phát hiện lỗi, thu thập các thông tin thống kê. Tất cả các hạ tầng mạng đang được quản lý bởi UCS Manager kết nối trực tiếp đến fabric interconnect hay kết nối thông qua fabric extenders. Các fabric extender có chức năng cung cấp các khả năng thêm vào trong việc kết nối các máy chủ vào fabric interconnect. Các thiết bị này không tốn nhiều công sức quản lý, chi phí thấp, tiêu hao năng lượng thấp và loại bỏ nhu cầu sử dụng các switch Ethernet and Fibre Channel switches.
Hình bên dưới mô tả các thành phần này kết nối với nhau:
Tất cả các máy chủ UCS hỗ trợ công nghệ SingleConnect. Cisco SingleConnect là một công nghệ hỗ trợ tất cả các loại lưu lượng từ các máy chủ (LAN, SAN, quản lý…) trên một kết nối vật lý duy nhất. Những gì công nghệ này giúp tiết kiệm chỉ là một phần của cấu trúc cáp đơn giản hóa. UCS Manager cung cấp giao diện HTML5 (GUI), giao diện CLI và một API đầy đủ. Tất cả các chức năng UCS và các đối tượng quản lý đều có sẵn thông qua UCS API. Các nhà phát triển có thể tận dụng các API mở rộng này và có thể nâng cấp nền tảng UCS theo các yêu cầu duy nhất. Các công cụ và các phần mềm tích hợp với các giải pháp từ các bên thứ ba như VMWare, Microsoft và Splunk đều được phổ biến rộng rãi.
Trong phần sau của chương, chúng ta sẽ thấy các công cụ UCS PowerTool for UCS Manager và Python SDK có thể được dùng để tự động hóa và lập trình quản lý UCS Manager. Với UCS Manager, các máy chủ trung tâm dữ liệu có thể được quản lý dùng IaC (Infrastructure As Code). Điều này là có thể thông qua các phát kiến bao gồm bên trong giải pháp UCS: hồ sơ dịch vụ (service profile). Hồ sơ dịch vụ là một cấu trúc luận lý bên trong UCS Manager chứa cấu hình đầy đủ của một máy chủ vật lý. Tất cả các thành phần của một cấu hình máy chủ, bao gồm các mức RAID, cài đặt BIOS, các phiên bản firmware, cài đặt adapter, cài đặt mạng và các thiết bị lưu trữ và các kết nối đến trung tâm dữ liệu đều được bao gồm trong hồ sơ dịch vụ. Khi một hồ sơ dịch vụ được kết hợp với một máy chủ, UCS Manager tự động cấu hình máy chủ, các adapter, fabric extenders và fabric interconnect để đúng với mô tả được chỉ ra trong hồ sơ dịch vụ. Với các hồ sơ dịch vụ, hạ tầng có thể được cấu hình trong vài phút thay vì vài ngày. Bạn có thể cấu hình sẵn các máy chủ và có các cấu hình này sẵn sàng trước khi các máy chủ kết nối vào mạng. Khi các máy chủ đã online và tìm thấy bởi UCS Manager, các hồ sơ dịch vụ có thể tự động triển khai đến các máy chủ.
Giao tiếp lập trình trong UCS Manager là XML API. XML API của UCS Manager chấp nhận các tài liệu XML trên các kết nối HTTP hay HTTPS. Cũng giống như ACI, các thông tin cấu hình và thông tin trạng thái của UCS được lưu trong một cấu trúc cây có thứ bậc được gọi là cây thông tin quản lý (Management Information Tree- MIT). Cây MIT chứa tất cả các đối tượng được quản lý trong một hệ thống UCS, có thể truy cập thông qua XML API. Bất kỳ ngôn ngữ lập trình nào cũng có thể được dùng để tạo ra các tài liệu XML, bao gồm các phương thức API. Một hoặc nhiều các đối tượng có thể thay đổi chỉ với một cuộc gọi API. Khi có nhiều đối tượng đang được cấu hình, các hoạt động API sẽ dừng nếu có bất kỳ một đối tượng nào không thể được cấu hình và hệ thống có thể quay trở lại trạng thái trước khi có sự thay đổi. Các hoạt động API làm việc theo phiên và được thực thi trên từng mô hình dữ liệu, tượng trưng cho toàn bộ hệ thống.
UCS Manager chịu trách nhiệm quản lý tất cả các giao tiếp đầu cuối, làm cho UCS Manager là nơi chứa thông tin chính xác nhất (single source of truth). UCS Manager giải phóng các nhà phát triển phần mềm ra khỏi việc quản lý các cấu hình của các thành phần riêng lẻ, tách biệt. Tất cả các yêu cầu XML là bất đối xứng (asynchronous) và kết thúc trong UCS Manager.
Tất cả các thành phần vật lý và luận lý tạo thành UCS được mô tả trong một cây thông tin quản lý (Management Information Tree - MIT), hay còn được gọi là Management Information Model (MIM). Từng nốt trong một cây được gọi là các đối tượng được quản lý (Managed Object - MO), là một nhóm của các đối tượng chứa các thông tin quản trị và các trạng thái hoạt động. Ở đỉnh của cấu trúc phân cấp này là đối tượng sys, chứa tất cả các nốt cha và nốt con trong cấu trúc cây. Từng đối tượng trong UCS có một tên duy nhất mô tả đối tượng và vị trí của nó trong cây. Mô hình thông tin này thường được lưu trữ trung tâm và quản lý bởi một tiến trình chạy trên các kết nối fabric interconnect được gọi là Data Management Engine (DME). Khi một thay đổi quản trị được kích hoạt đến một thành phần UCS, DMS đầu tiên sẽ áp dụng các thay đổi đến các mô hình thông tin, sau đó áp đặt các thay đổi tới các đầu cuối được quản trị. Giải pháp này được gọi là model-driven framework.
Một đối tượng quản trị cụ thể trong cây MIT có thể được nhận ra bởi tên distinguished name (DN) hoặc bởi tên liên quan của nó (relative name RN). DN xác định chính xác đối tượng được quản lý trong đó API call hoạt động và bao gồm một loạt các tên liên quan:
DN = {RN}/{RN}/{RN}/{RN}...
Một tên tương đối giúp xác định một đối tượng trong ngữ cảnh của đối tượng mức cha của đối tượng đang khảo sát. Mô hình UCS Manager XML API bao gồm các thành phần lập trình sau:
Lớp: Lớp định nghĩa các phương thức và các trạng thái của đối tượng bên trong cây MIT.
Phương thức: Định nghĩa các hành động mà API thực thi trên một hoặc nhiều đối tượng.
Kiểu: Các kiểu là các thuộc tính đối tượng thực hiện chuyển đổi các giá trị sang các trạng thái của đối tượng.
Có vài kiểu phương thức được hỗ trợ bởi XML API:
Phương thức xác thực: các phương thức này bao gồm các thành phần sau
aaaLogin: Phương thức login.
aaaRefresh: Làm mới các cookie dùng cho xác thực.
aaaLogout: Thoát khỏi phiên và ngừng sử dụng cookie xác thực tương ứng.
Phương thức truy vấn: Các phương thức này bao gồm các thành phần sau, được dùng để thu thập các trạng thái cấu hình của một đối tượng:
configResolveDn: Truy cập một đối tượng bởi DN.
configResolveClass: Truy xuất các đối tượng của một lớp cho trước.
configResolveParent: Truy xuất đối tượng cha của một đối tượng.
Phương thức cấu hình: Các phương thức này bao gồm các thành phần sau, được dùng để thay đổi cấu hình tới các đối tượng.
configConfMo: Ảnh hưởng đến MO.
configConfMos: Ảnh hưởng nhiều cây con.
Vì các phương thức truy vấn ở dạng XML API có thể trả về một số lượng lớn các dữ liệu, các bộ lọc có thể được hỗ trợ để giới hạn các kết quả này. Có bốn kiểu bộ lọc:
Lọc đơn giản: Các bộ lọc dạng đúng/sai này giới hạn các tập hợp kết quả của những đối tượng với các giá trị Đúng hay Sai.
Lọc theo các thuộc tính: Các bộ lọc này sử dụng các giá trị của các thuộc tính đối tượng như là các tiêu chí bao gồm trong một tập hợp kết quả (ví dụ equal filter, not equal filter, greater than filter).
Lọc tổng hợp: các bộ lọc này bao gồm hai hay nhiều các bộ lọc thành phần (ví dụ như AND filter, OR filter).
Bộ lọc thay đổi: Các bộ lọc này thay đổi kết quả của một bộ lọc container. Hiện tại chỉ có bộ lọc NOT là được hỗ trợ. Bộ lọc này phủ định kết quả của một container filter.
Các ứng dụng bên ngoài có thể thu thập thông tin thay đổi trạng thái của UCS bằng cách định kỳ truy vấn hay bằng webhook. Đăng ký nhận các biến cố xảy ra với hệ thống thông qua API là phương pháp được mong muốn hơn. Truy vấn polling thường sử dụng nhiều tài nguyên và nên được dùng trong những tình huống hạn chế.
UCS Manager có kèm theo một trình duyệt Visore giúp xem các đối tượng. Visore có thể được truy cập ở địa chỉ https://<UCS-Manager-IP>/visore.html. Bên dưới là giao diện trang web.
Toàn bộ cây thông tin quản trị MIT có thể được khám phá bằng công cụ Visore này. Ngoài ra các truy vấn cho một DN cụ thể cũng có thể chạy từ giao diện. Các tài nguyên liên quan đến UCS Manager có thể được tìm thấy ở địa chỉ https://developer.cisco.com/site/ucs-dev-center/.
Bước kế tiếp, hãy khảo sát các UCS XML API. Toàn bộ tài liệu đầy đủ của UCS cho các phiên bản khác nhau có thể được tìm thấy ở địa chỉ https://developer.cisco.com/site/ucs...ef-api-picker/. Ở site này, bạn có thể tìm tất cả các đối tượng đang quản lý, tất cả các phương thức, tất cả các kiểu, các báo lỗi và các luật FSM, và các tài liệu.
Để các nhà quản trị của các trung tâm dữ liệu có thể trở nên quen thuộc với hệ thống UCS, Cisco có phát hành một phần mềm mô phỏng. Phần mềm mô phỏng là một ứng dụng UCS được chạy bên trong một máy ảo VM. VM bao gồm các phần mềm mô phỏng các giao tiếp phần cứng cho hệ thống UCS. Phần mềm mô phỏng có thể tạo và thử nghiệm các cấu hình UCS hoặc để nhân bản một môi trường UCS cho mục đích khắc phục sự cố troubleshooting hay phát triển phần mềm. Phần mềm mô phỏng UCS phân phối dưới dạng file OVA và có thể chạy gần như trên môi trường ảo nào. Tài liệu đầy đủ cho UCS Manager cũng có trong phần mềm mô phỏng này.
Trong ví dụ bên dưới, chúng ta sẽ thử đăng ký dịch vụ sandbox. Sandbox là một dịch vụ lab online miễn phí của Cisco để giúp cộng đồng thử nghiệm các bài lab. Loại sandbox này có thể được đăng ký trước lên đến bảy ngày và chỉ dành cho những người đã đăng ký sử dụng. Có một UCS Manager Sandbox có thể được dùng để khảo sát XML API, ở địa chỉ https://developer.cisco.com/sandbox.
Sandbox này sử dụng phần mềm giả lập UCS Platform Emulator phiên bản 3.2(2.5). Ở thời điểm này, để xác thực và nhận một authentication cookie, chúng ta có thể dùng lệnh curl như ở bên dưới.
curl -k -X POST https://10.10.20.110/nuova \
-H 'Content-Type: application/xml' \
-d '<aaaLogin inName="ucspe" inPassword="ucspe"></aaaLogin>'
Địa chỉ IP của UCS Manager là 10.10.20.110, tài nguyên XML API ở địa chỉ /nuova và phương thức xác thực được dùng là aaaLogin. Tên người dùng và mật khẩu được truyền trong một tài liệu XML với biến là inName và inPassword. Trong cả hai trường hợp là ucspe. Phần header Content-Type chỉ ra kiểu dữ liệu mà cuộc gọi POST sẽ dùng để gửi đến XML API (trong trường hợp này dĩ nhiên là XML). Kết quả trả về phải tương tự như sau:
<aaaLogin cookie="" response="yes"
outCookie="1573019916/7c901636-c461-487e-bbd0-c74cd68c27be" outRefreshPeriod="600"
outPriv="aaa,admin,ext-lan-config,ext-lan-policy,ext-lan-qos,ext-lan-security,ext-san-config,ext-san-policy,ext-sansecurity,fault,operations,pod-config,pod-policy,pod-qos,podsecurity,read-only" outDomains="org-root" outChannel="noencssl"
outEvtChannel="noencssl" outSessionId="" outVersion="3.2(2.5)"
outName="" />
aaaLogin chỉ ra phương thức được dùng để login, giá trị “yes” xác nhận rằng đây là một kết quả trả về, outCookie cung cấp cookie cho phiên, outRefreshPeriod chỉ ra các chu kỳ làm mới cookie (mặc định là 600 giây), và giá trị outPriv chỉ ra mức phân quyền của tài khoản đăng nhập. Bước kế tiếp hãy truy cập danh sách của tất cả các đối tượng là một phần của lớp tính toán đang được quản lý bởi UCS Manager. Để hoàn thành việc này, chúng ta có thể dùng phương pháp configFindDnsByClassID. Phương thức này tìm ra các tên khác nhau và trả kết quả về bởi class ID.
Lệnh curl phải có dạng như sau:
curl -k -X POST https://10.10.20.110/nuova \
-H 'Content-Type: application/xml' \
-d '<configFindDnsByClassId
classId="computeItem"
cookie="1573019916/7c901636-c461-487e-bbd0-c74cd68c27be"
/>'
Đầu cuối XML API ở địa chỉ https://10.10.20.110/nuova, phần Content-Type header application/xml cũng vẫn như cũ. Dữ liệu XML đang được gửi đến UCS thì khác với ví dụ trước. Đầu tiên, phương tức configFindDnsbyClassID được chỉ ra và sau đó hai biến chủ chốt cho classID và cookie được truyền. ClassId chỉ ra lớp đối tượng, trong trường hợp này là computerItem và cookie đang được sử dụng giá trị đã có trước đây.
Kết quả trả về trong trường hợp này chứa một danh sách đầy đủ các thành phần đang được dùng bởi địa chỉ 10.10.20.110 của UCS Manager.
<configFindDnsByClassId
cookie="1573019916/7c901636-c461-487e-bbd0-
c74cd68c27be"
response="yes" classId="computeItem">
<outDns>
<dn value="sys/chassis-
4/blade-8"/>
<dn value="sys/chassis-
5/blade-8"/>
<dn value="sys/chassis-
6/blade-8"/>
<dn value="sys/chassis-
6/blade-1"/>
<dn value="sys/chassis-
3/blade-1"/>
... omitted output
<dn value="sys/rack-unit-9"/>
<dn value="sys/rack-unit-8"/>
<dn value="sys/rack-unit-7"/>
<dn value="sys/rack-unit-6"/>
<dn value="sys/rack-unit-5"/>
<dn value="sys/rack-unit-4"/>
<dn value="sys/rack-unit-3"/>
<dn value="sys/rack-unit-2"/>
<dn value="sys/rack-unit-1"/>
</outDns>
</configFindDnsByClassId>
Tiếp theo trong phần khảo sát UCS Manager XMP API, chúng ta hãy truy cập thông tin về một đối tượng cụ thể. Phương thức dùng để truy xuất một đối tượng riêng lẻ cho một DN cụ thể là configResolveDn.
Lệnh curl cho yêu cầu này có dạng
curl -k -X POST https://10.10.20.110/nuova \
-H 'Content-Type: application/xml' \
-d '<configResolveDn
cookie="1573019916/7c901636-c461-487e-bbd0-
c74cd68c27be"
dn="sys/chassis-4/blade-8" />'
Cũng giống như trong lần gọi trước, đầu cuối API và header Content-Type có cùng giá trị. Dữ liệu XML được gởi bên trong phần request chứa phương thức configResolveDn, các authentication cookie và DN mà chúng ta đang cần truy xuất thông tin. Trong trường hợp này, DN là blade server số 8 nằm trong chassis thứ tư. sys/chassis-4/blade-8.
Kết quả trả về được hiển thị bên dưới:
<configResolveDn dn="sys/chassis-4/blade-8"
cookie="1573019916/7c901636-c461-487e-bbd0-
c74cd68c27be" response="yes">
<outConfig>
<computeBlade
adminPower="policy" adminState="in-service"
assetTag=""
assignedToDn=""
association="none"
availability="available"
availableMemory="49152"
chassisId="4"
checkPoint="discovered"
connPath="A,B" connStatus="A,B" descr=""
discovery="complete"
discoveryStatus=""
dn="sys/chassis-4/blade-8" fltAggr="0"
fsmDescr=""
fsmFlags=""
fsmPrev="DiscoverSuccess"
fsmProgr="100" fsmRmtInvErrCode="none"
fsmRmtInvErrDescr=""
fsmRmtInvRslt=""
fsmStageDescr="" fsmStamp="2019-11-
06T04:02:03.896"
fsmStatus="nop"
fsmTry="0" intId="64508"
kmipFault="no" kmipFaultDescription=""
lc="undiscovered"
lcTs="1970-01-01T00:00:00.000"
localId="" lowVoltageMemory="not-applicable"
managingInst="A"
memorySpeed="not-applicable" mfgTime="notapplicable"
model="UCSBB200-
M4" name=""
numOf40GAdaptorsWithOldFw="0"
numOf40GAdaptorsWithUnknownFw="0"
numOfAdaptors="1"
numOfCores="8" numOfCoresEnabled="8"
numOfCpus="2"
numOfEthHostIfs="0"
numOfFcHostIfs="0" numOfThreads="16"
operPower="off"
operPwrTransSrc="unknown"
operQualifier="" operSolutionStackType="none"
operState="unassociated"
operability="operable"
originalUuid="1b4e28ba-2fa1-11d2-0408-b9a761bde3fb"
partNumber="" policyLevel="0"
policyOwner="local"
presence="equipped"
revision="0" scaledMode="none" serial="SRV137"
serverId="4/8"
slotId="8" totalMemory="49152"
usrLbl=""
uuid="1b4e28ba-2fa1-11d2-0408-
b9a761bde3fb"
vendor="Cisco Systems Inc"
vid=""/>
</outConfig>
</configResolveDn>
Mặc dù tương tác với UCS Manager XML API theo cách này vẫn tạm ổn, bạn sẽ thấy cách này nhanh chóng trở nên cồng kềnh. Cách được mong muốn hơn khi làm việc với XML API là thông qua công cụ UCS PowerTool hay UCS Python SDK. Cisco UCS PowerTool là một mô-đun giúp tự động hóa tất cả các phương diện của UCS Manager. PowerTool cmdlets làm việc trên UCS MIT. Cmdlets có thể được dùng để đọc, tạo mới, thay đổi và xóa các đối tượng trong cây Thông tin Quản lý MIT. UCS Power Tool cho phép dễ dàng tích hợp với các công cụ và tiến trình quản lý khác.
Bộ công cụ PowerTool có thể tải về từ địa chỉ https://community.cisco.com/t5/cisco...r/ta-p/3985798.
UCS Python SDK là một mô-đun Python giúp tự động hóa tất cả các khía cạnh quản lý UCS, bao gồm các máy chủ, mạng, vùng thiết bị lưu trữ và quản lý các hypervisor. UCS Python SDK làm việc trên UCS Manager MIT, thực hiện các tác vụ tạo mới, đọc, thay đổi hoặc xóa các đối tượng trong cây. Cả Python 2.7 và Python 3.5 đều được hỗ trợ. UCS Python mô-đun cho UCS Manager được gọi là ucsmsdk và có thể được cài đặt dùng pip với câu lệnh pip install ucsmsdk.
Phiên bản hiện tại của ucsmsdk của mô-đun là 0.9.8. UCS Python SDK cung cấp một công cụ được gọi là convert_to_ucs_python cho phép người quản trị và nhà phát triển các tùy chọn để lưu lại tất cả các tương tác với UCS Manager GUI và lưu nó trong một file XML. Chạy file XML này bằng công cụ convert_to_ucs_python tự động tạo ra các hành động được thực thi trong giao diện GUI. Sử dụng tiến trình này, các nỗ lực tự động hóa các trung tâm dữ liệu có thể được tăng tốc và các tác vụ đơn giản như tạo mới VLAN hay các tác vụ phức tạp chẳng hạn như cấu hình các mẫu chính sách dịch vụ mới có thể được tự động hóa trong vài giây.
Kế tiếp, hãy khảo sát UCS Python SDK và hãy xem làm thế nào để kết nối đến UCS Manager để truy xuất danh sách của tất cả các server blade trong hệ thống và cách thức truy xuất các thông tin trong các dữ liệu trả về. Đoạn chương trình mẫu Python được xây dựng từ
Python 3.7.4, sử dụng phiên bản 0.9.8 của mô-đun ucsmsdk.
Đầu tiên, lớp UcsHandle được nạp vào chương trình. Một phiên bản của lớp này được dùng để kết nối đến UCS Manager. Địa chỉ UCS Manager, tên người dùng và mật khẩu được truyền trong các thông số đến phiên bản của lớp UcsHandle, tạo thành một phiên bảngọi là HANDLE. Có vài phương thức có sẵn với lớp UcsHandle. Trong đoạn mã này, chỉ có ba loại phương thức được dùng.
HANDLE.login(): Phương thức này được dùng để truy cập vào UCS Manager.
HANDLE.query_classid(): Phương thức này được dùng để truy vấn cây MIT về các đối tượng với một classID cụ thể.
HANDLE.logout(): Phương thức này được dùng để logout ra khỏi UCS Manager.
Biến BLADES chứa một tự điển của tất cả các máy chủ blade đang được quản lý bởi phiên bản
UCS Manager ở địa chỉ 10.10.20.110. Bên trong vòng lặp for, các thông tin liên quan đến DN, số Serial Number, trạng thái quản trị, số model và tổng số bộ nhớ cho từng máy chủ được truy xuất và hiển thị ra màn hình.
Đoạn mã Python dùng UCS Manager SDK giúp hoàn thành tất cả các tác vụ này được mô tả trong hình bên dưới.
#! /usr/bin/env python
from ucsmsdk.ucshandle import UcsHandle
HANDLE = UcsHandle("10.10.20.110", "ucspe","ucspe")
# Login into Cisco UCS Manager
HANDLE.login()
# Retrieve all the compute blades
BLADES = HANDLE.query_classid("ComputeBlade")
print('{0:23s}{1:8s}{2:12s}{3:14s}
{4:6s}'.format(
"DN",
"SERIAL",
"ADMIN STATE",
"MODEL",
"TOTAL MEMORY"))
print('-'*70)
# Extract DN, serial number, admin state,
# model, and total memory for each blade
for BLADE in BLADES:
print('{0:23s}{1:8s}{2:12s}{3:14s}
{4:6s}'.format(
BLADE.dn,
BLADE.serial,
BLADE.admin_state,
BLADE.model,
BLADE.total_memory))
HANDLE.logout()
Kết quả của chạy đoạn scrip này được trình bày bên dưới: