ẢO HÓA

VMware vSphere 5 : Tăng cường vMotion với cấu hình Multi-Nic

Nếu như các bạn người đang đọc bài viết này đã từng tim hiểu những cải tiến trong phiên bản vSphere 5 thì bài viết này hoàn toàn “đơn giản”. Trong bài viết này tôi sẽ không đi hết tất cả những NEWs trong vsphere 5 mà chỉ một phần nhỏ của mãng Network (New networking features) đó chính là tăng cường hiệu suất của tính năng vMotion thông qua cấu hình load trên nhiều NIC hay còn gọi là Multi-Nic vMotion. Với những phiên bản trước bao gồm cả 4.0 và 4.1 thì giới hạn mà vMotion mắc phải đó chính là traffic chỉ tập trung ở một NIC  và hoàn toàn không thể có khái niệm loadbalancing cho các traffic vMotion. Và từ phiên bản vSphere 5 đã giải quyết hoàn toàn bài toán đó mà không cần bất cứ thay đổi nào về cấu hình physical switch hay các tùy chọn cấu hình có ảnh hưởng đến hệ thống trên vCenter.

Trước khi đi qua vấn đề chình thì chúng ta sẽ đi qua một số chú ý về giới hạn vMotion trong phiên bản này dính líu một phần trong việc cấu hình Multi-Nic:

Số lượng NIC tối đa dành cho vMotion trong vSphere 5 (cho mỗi host) là:

• 1GbE – 16 NICs
• 10 GbE – 4NICs

Số lượng vMotion cho phép tại một thời điểm (cho mỗi host)

• 1 GbE – 4 vMotions
• 10GbE – 8 vMotions

Hướng dẫn cấu hình Multi-Nic vMotion

Chú ý: bài này chỉ hướng dẫn trên hệ thống sử dụng vDS (distributed switch) standard switch sẽ có cấu trúc tượng tự.

Bước 1: Tạo một vDS dành cho vMotion với n port group với n là số lượng NIC sẽ dùng cho cấu hình Multi-Nic vMotion

Trong hướng dẫn cấu hình này, tôi sử dụng hai NIC 1GbE và một vDS dành riêng cho vMotion trong đó tên các port groups lần lượt là vMotion_1 and và vMotion_2.  Nên nhớ rằng các bạn chỉ có tối đa được cấu hình 16 NIC cho đường truyền 1GbE và 4 NIC cho đường truyền 10GbE qui tắc đặt tên có thể tham khảo như tôi  vMotionx, vMotion_(x+1),… vMotion(n).

Bước 2: Add các Hosts ESXi vào vDS vMotion vừa tạo với các NIC Uplink được chọn dùng cho cấu hình Multi-Nic vMotion

Bươc 3: quay lại Edit mỗi port group ở đây vMotion_1 và vMotion_2  vào mục Nic Teaming cấu hình Failover Order sử dụng một Active Uplink tất cả uplink còn lại cho standby. Cấu hình này cần đảm bảo mỗi Nic Uplink chỉ dành riêng cho một port group  và nó phải là active uplink còn lại là stanby uplink.

Ví dụ:

Port group vMotion_1 dùng dvUplink1 như active link và dvUplink2 như Stanby Uplink

Port group vMotion_2 dùng dvUplink2 như active link và dvUplink1 như stanby Uplink

Bước 4: cấu hình p số lượng VMkernel Ports cho mỗi host với p là số lượng Port Group cấu hình cho vMotion ( nó cũng tương tự như số lượng Nic uplink dùng cho vMotion bên trên). Gán mỗi VMkernel port tới một Port Group chỉ dành riêng cho nó.

Lúc này trong mục Configuration của vDS sẽ có cấu trúc như sau:

Kết quả đạt được

Trường hợp 1: một hành động vMotion trên đường truyền 1 Nic 1GbE

• 884Mb/s transferred through vmk1
• 26s average virtual machine migration time

Trường hơp 2: Kết quả vMotion cho cấu hình Multi-Nic vMotion với 2 Nic Uplink

• 1774Mb/s transferred through vmk1 (886.74Mb/s) and vmk2 (886.84Mb/s)
• 16s average virtual machine migration time

Ta sẽ nhận thấy rằng hiệu suất tăng cường đáng kể với 101% dữ liệu thực được truyền đi và thời gian chỉ tốn 63% so với cấu hình truyền thống trước kia.

Một điều cần chú ý trong quá trình truyền tải vMotion (với cấu hình Multi-Nic) tất cả uplink vMotion của Host nguồn sẽ đều hoạt động truyền data và tất cả uplink vMotion của Host địch đều có nhiệm vụ nhận data đó. Đây là điều làm nên sự thay đổi đáng kể khi vận dụng cấu hình này.

Sau đây là bảng số liệu mô tả traffic truyền và nhận giữa hai Host nguồn và đích:

Tổng kết:

Multi-Nic vMotion không chỉ tăng cường hiệu suất trong vấn đề migration máy ảo mà còn là tiền đề cho các giải pháp tự động hóa khác trong môi trường VMware:

1. Tăng cường hiệu quả việc phân phối và sử dụng tài nguyên hệ thống trong chế độ DRS Fully Automated

2. Giảm thời gian bảo trì Host trên hệ thống đặc biệt là trong các môi trường ảo hóa lớn với tỷ trong máy ảo trên một Host nhiều.

VMware vSphere 4: Tổng quan virtual network

Ngay từ những phiên bản đầu tiên Vmware đã khẳng định được vị thế của mình trong làng công nghệ ảo hóa. Không đơn thuần mà Vmware được đánh giá cao như thế nó là sự nỗ lực nghiên cứu phát triển không ngừng trong lĩnh vực ảo hóa máy chủ. Hạ tầng Virtual Network của Vmware tiềm tàng các đặc tính mạnh mẽ nhất hỗ trợ tối đa cho các thiết kế hạ tầng network enterprise. Chúng có thể được quản lý riêng lẻ trên từng cá thể host của môi trường ảo cũng như  quản lý tập trung nhất thông qua sản phẩm Vmware vCenter.

Nhìn chung hạ tầng network của Vmware gồm các thành phần như hình sau:

Tình từ trên xuống có các thành phần như sau:

Nic ảo (card mạng ảo) là thiết bị network giao tiếp chính giữa các VMs với hạ tầng network bên dưới cả ảo lẫn physical. Trong quá trình dài phát triển của mình VMware cho ra đời nhiều phiên bản, dòng Nic ảo khác nhau cho môi trường ảo như

• Vlance ( một dạng cacrd hỗ trợ cho các dòng OS cũ chỉ support 10Mbps
• VMxnet là một dòng card hỗ trợ tối ưu hóa network cho các VMs nhưng đòi hỏi phải cài đặt driver trong Vmware Tools
• Flexible là một định nghĩa card khá đặc biệt nếu sử dụng nó thì bạn đầu boot và sử dụng network sẽ hoạt động như Vlance khi thiết lập vmware tools và cái đặt các driver vmware thì sẽ hoạt động ở dạng VMxnet
• E1000: tiếp theo đó là sự ra đời cho dòng Nic E1000 nó là kết quả của quá trình giả lập hoạt động cấu trúc của card Intel 82545EM Gigabit Ethernet NIC. Tuy nhiên driver của thiết bị này không có sẵn trên tất cả OS mà chỉ có trên các phiên bản từ Linux versions 2.4.19, Windows XP Professional x64 Edition và  Windows Server 2003 (32-bit) trở lên.
• Về sau là sự phát triển của dòng VMxnet là VMxnet2 và VMxnet3 ngoài nâng cao khả năng hiệu suất còn có một số tính năng đặc biệt khác như jumbo frames , hardware offloads…

P/s: một VM tối đa được add 10 Nic ảo

Bản thân Host ESX/ESXi cũng sẽ có một hoặc nhiều Nic ảo để dành cho hoạt động giao tiếp với bên ngoài như vCenter. Trong các phiên bản trước thì đối với trường hợp này sẽ có 2 khái niệm:

Service Console: thực chất chỉ là tên một tên gọi bản chất của nó là một OS thu nhỏ gồm nhiều thành phần service: firewall, Simple Network, Management Protocol (SNMP) agents, web server…phục vụ cho nhu cầu tương tác với ESX và VMs được đóng gói sẵn trong các phiên bản trước nhằm cung cấp các giao diện quản lý trực tiếp trên host. Nhưng vì trong quá trình vận hành chúng trở nên không cần thiết nên đuợc lược bỏ đi trong các phiên bản sau này (từ bản 4 là không còn).

VMKernel: là lõi điều khiển chính cho toàn bộ hoat động bên dưới của các VMS hỗ trợ tương tác với phần cứng như quản lý lịch CPU, quản lý memory cũng như các tiến trình xử lý network bên trong các vswitch VMkernel bản thân nó cũng có một IP riêng dùng cho việc liên lạc với vCenter, vMotion, Fault tolerance, quản lý từ xa….

Lớp kế tiếp trong môi trường mạng ảo của Vmware là thành phần quan trong nhất nó chính là hệ thống các switch ảo. Mặc định mỗi host ESX/ESXi sẽ có một hệ thống switch riêng gọi là Virtual Standard Switch (vSwitch)

Mỗi host sẽ có một bộ vSwitch trong bộ đó sẽ có nhiều switch ảo. Trên mỗi vSwitch sẽ có nhiều port ngoài port cho service console và vmkernel dành cho host thì các port còn lại dành cho máy ảo nên còn gọi là VM port tuy nhiên trên các vSwitch để có thể plug Nic ảo vào vSwitch chúng ta cần thiết lập nên các nhóm port (Port Group) để có thể tùy nhu cầu mà thiết lập các policy khác nhau cho các nhóm port khác nhau ( I/O, Vlan, failover…) ngoài ra để đi ra được môi trường mạng bên ngoài thì mỗi vSwitch cần có ít nhất một Nic thật hay còn gọi là uplink mỗi vSwitch có thể mang theo nhiều uplink để failover, Load Balancing (tập hợp các uplink lúc này gọi là Nic Teaming) tuy nhiên chú ý là một NC thật chỉ  thuộc một vSwitch. Một số tác dụng của vSwitch như sau:

• Kết nối các máy ảo trong cung một host
• Kết nối giữa các máy ảo khác host với sự hỗ trợ của các uplink
• Kết nối giữa các máy ảo và máy vật lý trong hệ thống mạng
• Phuc vụ cho các truy cập Service console (chỉ trên ESX)
• Phục vụ VMkernel phục vụ mục đích  VMotion, iSCSI, NFS, hoặc fault tolerance logging và quản lý trên ESXi.

Trên cơ bản vSwitch hoạt động không khác gì các switch thông thường tuy nhiên chúng không hỗ trợ các giao thức STP, VTP. Vì trong môi trường mạng thật nhiệm vụ của switch là kết nối và mở rộng thêm hạ tầng tuy nhiên trong môi trường ảo thì các switch ảo trên đó có thể có hằng trăm port nên việc kết nối các switch lại để mở rộng hạ tầng là không cần thiết. Đồng nghĩa việc các switch ảo này nằm ở lớp access cuối cùng không kết nối thêm switch nào nữa nên không xảy ra loop mà không xảy ra loop thì không cần STP đồng thời cũng chẳng có môi trường để cần sử dụng giao thức VTP. Nhưng vẫn hỗ trợ Vlan nhưng theo một phương thức khác điền hình là 3 loại thiêt kế:

• Virtual switch tagging (VST mode)
• Virtual machine guest tagging (VGT mode)
• External switch tagging (EST mode)

Tuy nhiên việc sử dụng vSwitch trong môi trường mạng thật tế đã đem đến nhiều phiến phức trên mỗi host phải cấu hình từng bộ vSwitch, port group… để đảm bảo tính chung nhất cho toàn hệ thống đảm bảo cho các tính năng Migration do đó bài toán đặt ra là chúng ta cần một hệ thống vDS có thể quản lý tập trung được. Và để giải quyết bài toán tập trung này VMware đã xây dựng lên một khái niệm switch mới và chỉ có thể cấu hình và phân phôi từ vCenter Server gọi là Virtual Distributed Switch (vDS). Cấu hình sẽ được lưu trong database và phân phối đến từng host qui định.

So Sánh vSwitch và vDS

Ngoài việc khác nhau ở mặt quản lý tập trung thì hoạt bên trong giữa vSwitch và vDS vẫn có một số giống và khác nhau:

Giống nhau:

• Đều làm việc ở Layer 2
• Hỗ trợ việc đóng gói và vận chuyển vlan
• Có thể có một hay nhiều uplink (Nic teaming)
• Quản lý I/O chiều ra cho các luu thông traffic

Khác nhau (chỉ trên vDS):

• Hỗ trợ quản lý I/O cả hai chiều
• Quản lý tập trung qua giao diện quản lý của vCenter Server
• Hỗ trợ Private vLan (PVLANS)

Ngoài ra còn một loại switch ảo đặc biệt thuộc hãng thứ 3 là Cisco phát triển đưa vào hoạt động trong môi trường ảo của VMware gọi là Cisco Nexus 1000 loại này cũng tương tự như vDS đều có thể quản lý tập trung. Tuy nhiên đây là sản phẩm dựa trên nền tảng network của Cisco nên nó mang lại những khác biệt vượt trội về policy, security, QoS…

Qua phần 1 của loạt bài về netowrk này hẳn các bạn đã nắm rõ sơ bộ về “hình hài” của hệ thống virtual network trong VMware vSphere 4. Nếu chưa rõ vui lòng xem lại VMware vSphere 4: Tổng quan virtual network (P.1). Tiếp theo loạt bài này chúng ta sẽ đi sâu về các thuật ngữ , các tính năng tùy chọn trong một Virtual Switch (vSwitch lẫn vDSwitch).

Trước hết chúng ta cần view lại một tý về một ví dụ điển hình khi thiết kế một vSwitch

Trong ví dụ bên trên là một vSwitch điển hình với một Port Group dành cho máy ảo và một VMkernel dành cho việc quản lý, vmotion, smotion… của máy host. Và ở đây chúng ta cần nhắc lại một số quy tắc:

• Một vNic chỉ plug được một port trong portgroup trên vSwitch
• Một host có thể có nhiều vSwitch cùng tồn tại
• Một vSwitch có thể có nhiều port manangement cũng như có thể có nhiều port group với các policy khác nhau như Vlan, security, control I/O network…
• Và để traffic network để đi ra được hệ thống switch physical thì chúng ta cần một đến nhiều uplink (NIC physical) khi mà một vSwitch có hơn hai uplink thì một tính năng đặc biệt sẽ có trong từng Port Groupđược gọi là NIC teaming

 NIC TEAMING

Ban đầu NIC Teaming trong một portgroup sẽ mặc định disable trừ khi chúng ta bật tính năng này lên. Tính năng này cho phép chúng ta quy định các thức làm việc của một nhóm các uplink trong một portgroup với sự hỗ trợ của các tùy chọn : load balancing, failover…

Xin nhắc lại là tính năng này là một policy về loadbalancing và failover nó chỉ được cấu hình ở mức độ portgroup thay vì vSwitch vì đơn giản policy này sẽ giúp chúng ta uyển chuyển hơn trong việc quản lý các nhóm máy ảo trên hệ thống với cơ chế loadbalancing, failover khác nhau.

Trong tính năng này cái chúng ta quan đầu tiên và quan trọng đó là các thức để load balancing các port uplink với bất cứ luồng traffice nào từ portgroup cấu hình muốn đi ra mạng physical bên ngoài.

Chúng ta tổng cộng có tất cả 4 cách thức Load Balancing khác nhau được VMware hỗ trợ:

Route based on the originating virtual port ID

Trong phương thức cân bằng tải này sẽ dựa trên cơ chế mỗi port trong một port group sẽ mapping (ánh xạ) với một physical NIC bằng cách chia đều port cho các card physical như hình sau

Một số điều lưu ý là chúng sẽ không quan tâm đến VM bên trên nên sẽ có trường hợp một VM 2 vNic có thể sẽ cùng dùng chung một physical Nic. Và bên cạnh đó với phương thức này tại một thời điểm một vNIC chỉ có thể đi ra một physical NIC. Nên phương thức này không thể xem như một phương thức cân bằng tải hiệu quả.

Kết quả cũng diễn ra tương tự với phương thức tiếp theo

Route based on source MAC hash

Với phương thức Route based on the originating virtual port ID thay vì dựa theo thứ tự port để phân chia ra các physical NIC thì với phương thức thứ hai này lại dựa vào MAC address cùa  vNIC để phân chia việc mapping physical nên gần như kết quả không gi mới mẻ so với phương thức đầu.

Đển với phương thức thứ 3 cũng là phương thức được đánh giá là giải quyết được bài toán Load Balancing thực sự

Route based on IP hash

Tại sao phương thức này được đánh giá cao về loadbalancing đo chính là vì phương thức chọn physical NIC của nó cực kỳ linh động với nhiều trường hợp. Phương thức của nó dựa trên việc băm (IP source + IP dest) và kết quả đó sẽ được dùng để quyết định lần lượt mỗi des IP khác nhau sẽ đi ra một physical NIC khác nhau. Giải quyết bài toán là tại một thời điểm có thể dùng cả physical NIC. Điển hình với 2 physical NIC 1GB chúng ta có thể đạt tới mức sử dụng 2GB thay vì dùng 2 phương thức trên chỉ tối đa một NIC 1GB.

Tuy nhiên nó không có lợi trong trường hợp một session truyền tải một lượng lớn data vì tất cả cũng chỉ sẽ đi qua một uplink do chi có một dest duy nhất trong một session. Ngoài ra với kiểu thiết kế dung Route baed on IP hash thì các up link phải cũng nối vào một physical switch để không gặp tình trạng một physical switch sẽ thấy MAC Vm trên nhiều port switch khó để dự đoán NIC nào sẽ nhận được gói tin trả về. Chú ý một điều “Route based on IP hash” chỉ quản lý chiều đi còn chiều về là tùy thuộc switch physical nhưng do switch physical đều lưu bảng Mac table rằng có nhiều port ra cho cùng một MAC address hiển nhiên nó sẽ broadcast ra các port đó. Nên thường thiết kế sử dụng Ethernet Channel để đạt hiệu quả cao hơn cho cả hai chiều.

Bên cạnh đó với thiết kế các uplink hoạt động dạng Ethernet Channel trên physical switch thì chỉ có một policy là route based on IP hash là có thể sử dụng trong trường hợp này.

Use explicit failover order

Phương thức này hoạt độngdựa theo thứ tự sắp xếp các NIC trong bảng như bên dưới để quyết định NIC hoạt động.

NETWORK FAILOVER DETECTION

Bản thân NIC teaming ngoài mặt hoạt động loadbalancing thì bản thân nó còn có khả năng xử lý failover. Tuy nhiên cái mà chúng ra quan tâm là làm sao nhận dang là failed. Bao gồm 2 tùy chọn:

Link status only

Phương thức này xác định một uplink là failed dựa trên trạng thái port của uplink. Khi port này mất tin hiệu với switch đồng nghĩa với việc việc nó failed. Tuy nhiên mấu chốt đây là nó chỉ có thể nhận dang failed với switch gần nhất cắm trực tiếp vào nó.

Trong khi hệ thống mạng chúng ta có thể có nhiều switch nối với nhau và nó trợ thành điểm yếu chết người cho phương thức này. Nó có thể nhận dạng failed trên switch thứ 1 gần nó nhưng khi switch thứ 2 thứ 3.. có tình trạng port failed thì nó không nhận dạng được. Để giải quyết tình thế này chúng ta cần áp dụng khái niệm gọi là Link state Tracking (cisco) hãng khác còn có tên gọi là Link Dependency

Tính năng này cho phép nhóm các port có mối liên hệ với nhau thành nhóm “quan hệ” với nhau. Ví dụ như hình trên port nối với uplink trái là port A và port còn lại trên cung switch là port B. Lúc này 2 port A và B chúng ta cấu hình Link state Tracking thì khi đầu B failed thì đồng nghĩa đầu A failed chung để giải quyết trường hợp bên trên khi đường đi switch 2 switch 3 failed… Trên thực tế Link State Tracking cần được cấu hình liên tục cả một chuỗi các switch đảm bảo bất cứ segment nào down cũng sẽ được hê thống VMware nhận dạng.

Beacon Probing

Ngoài việc có thể giải quyết bằng link state tracking VMware còn đưa ra một tùy chọn mới là Beacon Probing đây là một cơ chế đặt ra nó liên tục theo thời gian gửi đi và lắng nghe các tin phản hồi trên tất cả các NIC trong team và dùng thông tin này để nhận định tình trạng failed trên các NIC. Mục tiêu đặt ra cho cơ chế này là nhận dạng failed trong các trường hợp về cáp, switch bao gồm cả switch trực tiếp với NIC và các switch khác trên đường đi traffic, bên cạnh đó hỗ trợ một phần nào đó việc xác nhận cấu hình sai Vlan, port.. trên hệ thống switch.

Phương thức hoạt động của Beacon là theo định kỳ gửi các gói tín hiệu broadcast (tất cả VLAN đang có) ra tất cả các NIC trong Team.  Các physical switch lúc này sẽ tiếp nhận và đẩy ra các port cùng broadcast domain. Bên cạnh đó các NIC khác trong Team sẽ là các đối tượng chính tiếp nhận gói tin này. Nếu sau khi gửi tin bất kỳ một uplink nào trong Team không nhận được “3 tín hiệu” liên tục đồng nghĩa nó đang trạng thái lỗi.

Trên thực tế Beacon chỉ có lợi điểm khi hoạt động trong một nhóm nhiều hơn 3 NIC bởi khi chỉ có 2 NIC một khi fail xảy ra hệ thống sẽ không đảm bảo việc NIC nào sẽ đặt trong trạng thái fail loại bỏ việc sử dụng nó vì lúc này cả hai đều không nhận được tín hiệu của nhau.

Notify switches

Đây là một tùy chọn nhăm hỗ trợ giảm thời gian xây dựng lại bảng MAC table trên các switch thật. Cơ chế như sau khi NIC Teaming xảy ra bất kỳ sự kiện nào trong danh sách sau:

• Máy ảo được khởi động
• Một sự kiện vMotion xảy ra
• MAC address máy ảo bị thay đổi
• Failover và Failback trong NIC teaming xảy ra

Một khi xảy ra một trong các sự kiện say hệ thống sẽ sử dụng Reverse Address
Resolution Protocol (RARP) để thông báo sự thay đổi cho hệ thống switch thật về vị trí máy ảo hoặc MAC address trên hệ thống ảo giảm độ trễ cho phần network khi vMotion, change MAC address… xuống thấp nhất có thể.

Failback

Tính năng này cho phép khôi phục trạng thái active của một Uplink khi trải qua trang thái failed và đã được khôi phục chức năng.

Traffic Shapping

Là một tính năng hỗ trợ việc giới hạn băng thông “đi ra” (outbound) trên nhóm port group cụ thể bao gồm trong đó là 3 thông số cấu hình chính:

• Average Bandwidth – lượng data trung bình mỗi giây truyền qua vSwitch
• Peak Bandwidth – băng thông tối đa mà vSwitch có thể cho qua
• Burst size – lượng data tối đa trong một chu kỳ

Security

Về bảo mật thì trong port group khá hạn chế chủ yếu gồm có 3 thông số chính:

Promiscuous Mode: mặc định là tắt trên tất cả máy ảo. Tính năng này sẽ hạn chế việc nghe trôm các gói tin unicast của các đối tượng khác trong cùng network.

MAC Address Changes: Đảm bảo sự toàn vẹn của các luồng traffic thông qua vSwitch đến máy ảo. Nếu cấu hình Reject thì mọi traffic đến VM sẽ bị drop nếu như Mac address trong file cấu hình VMware khác Mac Address hoạt động trong quá trình truyền tải dữ liệu

Forged Transmits: Đảm bảo sự toàn vẹn của các luồng traffic từ VMs đi đến vswitch. Khi bật reject hệ thống sẽ drop mọi traffic đi ra nếu như Mac address trong file cấu hình VMware khác Mac Address hoạt động trong quá trình truyền tải dữ liệu

Vì thế khi cấu hình Network Load Balancing nên chú ý cấu hình Accept cho hai tính năng MAC Address Changes và Forged Transmits

Cấu hình VMware Distributed Power Management (DPM) trong VMware

Giới thiệu

“Going Green” là đang là một xu hướng mạnh mẽ. Hẳn bạn cũng từng thấy các quảng cáo của IBM khi những chú chim và sóc nhảy ra bên ngoài và màn hình chuyển màu xanh khi công ty chọn “go green”. Vì vậy, “go green” đã trở thành một từ sáo rỗng. Tuy nhiên, những ứng dụng thực tiễn của điều này lại hoàn toàn hợp lý. Bằng cách sử dụng các chức năng tiết kiệm năng lượng và ảo hoá như DPM, bạn có thể tiết kiệm đến 40% chi phí điện cũng nhưng những cái lợi khác của việc sử dụng ảo hoá

VMware’s Distributed Power Manager (DPM) is part of VMware’s Distributed Resource Scheduler (DRS). Just as DRS works to optimize the resource load across multiple ESX host servers, DPM can fit into that by migrating VM guests off of servers that are not in use and shut the host system down. Even better, once you configure DRS, using DPM is virtually a “checkbox away”.

Distributed Power Manager (DPM) của VMware là một phần của Distributed Resource Scheduler (DRS). Cũng như DRS hoạt động để tuỳ chỉnh các tải tài nguyên trên nhiều server host ESX, DPM có thể khớp vào nó bằng cách di trú VM ra khỏi các server không sử dụng và tắt hệ thống host. Hay hơn là một khi bạn cấu hình DRS, sử dụng DPM là một checkbox từ xa một cách ảo hoá

VMware mô tả DPM

“VMware DRS có những khả năng phân bổ quản lý năng lượng (DPM). Khi DPM được bật lên, hệ thống so sánh công suất mức độ cluster và mức độ host với nhu cầu của các máy ảo đang chạy trong cluster. Dựa trên những kết quả so sánh này, DPM đề xuất (hay tự động thực hiện) những hàng động nhằm giảm bớt tiêu thụ năng lượng của cluster.” 
Tại sao lại có những server được bật lên nhưng lại không cần và không được sử dụng? Điều này giống như để đèn bật trong văn phòng của bạn rồi về nhà cả ngày – thật lãng phí điện và tiền của cho công ty. DRS cũng có thể tự động tắt điện các server không cần

Cùng cấu hình DPM

Làm sao để cấu hình VMware Distributed Power Management (DPM)?

Trước khi tôi hướng dẫn các bạn cấu hình VMware Distributed Power Management, chúng ta hãy cùng bắt đầu bằng một vài yêu cầu đảm bảo bạn đáp ứng được.

VMware Virtual Infrastructure Suite Enterprise (hay có thể mua riêng)

Hai hay ba các server host ESX đã được cài đặt và đang chạy

LAN (WOL) có sẵn đã wake on và được kích hoạt trên các server host ESX

VMware Virtual Center quảng lý những server host này.

Nếu bạn không chắc server vật lý của mình (ESX host system) hỗ trợ WOL, bạn có thể khởi động server bên trong VI Client, đến Configuration Tab, sau đó click vào Network Adaptors, và bạn sẽ thấy cột Wake on LAN Supported, như hình bên dưới.

Hình 1: Kiểm tra xem adaptor của bạn hỗ trợ WOL

Chú ý rằng bạn cũng cần vào BIOS của server và đảm bảo Wake on LAN được kích hoạt.
Tiếp theo, vào VI Client Configuration -> mục Networking và đảm bảo adaptor tương ứng với VMkernel vSwitch của server cũng là adaptor hỗ trợ WOL. Nếu không phải trường hợp này, bạn cần sắp xếp lại adaptor bởi vì DPM sử dụng VMkernel vSwitch NIC của người dùng.

Hình 2: Kiểm tra adaptor VMkernel của bạn có kết nối với adaptor vật lý WOL không

Bạn có thể kiểm tra WOL một cách dễ dàng bằng cách dùng VMware ESX và VI Client. Để làm được điều này, VMotion đưa sản phẩm VMs từ một host ESX, đưa host ESX vào chế độ standby. Tiếp theo, wake up nó bằng cách sử dụng Power On, trong VI Client, cho host này.

Tiếp theo, bạn cần tạo một ESX Server Cluster chuẩn bằng cách chuột phải vào datacenter, sau đó click vào New Cluster.

Hình 3: Khởi tạo một cluster DRS

Hình 4: Tạo một DRS kích hoạt Cluster

Tất nhiên là bạn có thể làm nó là một cluster HA.

Thực hiện tất cả các cấu hình cài đặt cluster thông thường, xem lại cấu hình của bạn ở bước cuối cùng, và click vào Finish để tạo cluster DRS của bạn (ngay sau đó là DPM) 
Bây giờ bạn đã có cluster của mình, chuột phải vào cluster và click Edit Settings, như bạn đã thấy trong hình 5

Hình 5: Thay đổi các cài đặt trong một VMware DRS Cluster

Bên trong màn hình cài đặt cluster, bên dưới VMware DRS, bạn có thể click vào Power Management, như hình 6

Hình 6: Các mục Power Management cho DRS Cluster

Với các mục quản lý năng lượng cluster, bạn có thể chọn hoặc là 1) tắt DPM cho cluster, 2) cài cluster thành DPM bằng tay hay 3) cài cluster thành DPM tự động. Bạn cũng có thể override bằng tay các cài đặt DPM cho mỗi host ESX trong cluster đó ở mục Host Overrides của màn hình Power Management (hình 6)

Bây giờ hãy nói một chút về việc cài đặt tự động và bằng tay. Với một cluster DPM bằng tay, DPM sẽ đề xuất để tắt hay bật các server trong cluster của bạn dựa trên nhu cầu. Bạn có thể thấy một trong những đề xuất này trong hình 7 và kết thúc những đề xuất này ở hình 8.

Hình 7: Các đề xuất DPM cho một cluster DPM bằng tay

Hình 8: Các đề xuất DPM cho một cluster DPM

Trong hình 7, bạn có thể thấy cách chọn Apply Recommendation và chấp nhận tắt điện. 
Mặt khác, với một cluster DPM tự động, guest được di trú tự động ra khỏi một host không cần và host đó sẽ tự động tắt. Nếu có thắc mắc gì, bạn sẽ thấy trong mục Events của VI Client của mình mà guest VM đã được di trú và host là “Entering Standby Mode”. Ví dụ như hình 9.

Hình 9: ESX Host trong một cluster DPM đang đi vào Standby Mode vì Automatic DPM

Bạn có thể nói được tình trạng của cluster DRS/DPM của mình bằng cách nhìn vào tab Summary của cluster như bạn thấy ở hình 10.

Hình 10: Tab Summary của DRS/DPM Cluster trong chế độ Automatic

Tôi khuyên các bạn nên dùng chế độ tự động nhưng bạn cũng nên kiểm tra nó trong chế độ bằng tay trước.

DPM vẫn đang thử nghiệm?

Đúng vậy, DPM vẫn được xem là một tính năng thử nghiệm. Khi bạn kích hoạt DPM lần đầu tiên, bạn sẽ thấy cảnh báo sau, như hình 11.

Hình 11: Cảnh báo về DPM vẫn đang thử nghiệm

Tuy nhiên, tôi vẫn hy vọng điều này sẽ không ngăn cản bạn dùng thử DPM, sau đó sử dụng chính thức một khi bạn đã tự tin với DPM. Thật ra những tính năng thành công và hữu ích nhất của VMware vẫn chỉ được xem là “Experimental”

Liệu tôi có thể xem VMware DPM hoạt động thực sự?

Dù bạn đang dùng VMware DPM hay chỉ mới nghĩ đến, tôi khuyên mọi người nên xem video trên Youtube mô tả VMware DPM đang hoạt động. Bằng chúng về sức mạnh của DPM ở ngay trong video này.

Kết luận

Trong bài viết này, tôi đã nói về cách cấu hình từng bước VMware Distributed Power Management (DPM). Một phần distributed resource scheduler (DRS) của VMware, DPM được dùng để di trú VM guest ra khỏi các server không dùng và tắt hệ thống host. Điều này có thể tiết kiệm một lượng lớn tài nguyên cơ sở dữ liệu

Trung Nghĩa (Theo QTM , Virtualizationadmin)

Follow Up: HA Change (isolation response)

I’ve been asking around why the default isolation response has been changed from “power off” to “leave powered on”. It seems that this is done because a lot of customers had VM’s being powered off unnecessary. This happened because the service console or physical switches weren’t setup redundant and thus caused HA to kick in. In other words, for those having complete redundancy, switches and nics, change the default back to “power off” or use the new option “Shutdown VM”.

Shutdown VM requires VMware Tools to be installed. If HA is unable to shutdown the VM within 5 minutes it will be powered down. I would prefer this option, especially when you virtualized services like Exchange, SQL, Oracle etc.

Which isolation response should I use?

I wrote this article about split brain scenarios for the vSphere Blog. Based on this article I received some questions around which “isolation response” to use. This is not something that can be answered by a simple “recommended practice” and applied to all scenarios out there. Note that below has got everything to do with your infrastructure. Are you using IP-Based storage? Do you have a converged network? All of these impact the decision around the isolation response.

The following table however could be used to make a decision:

vSphere HA Isolation response when using IP Storage

I had a question from one of my colleagues last week about the vSphere HA Isolation Response and IP Storage. His customer had an ISCSI storage infrastructure (applies to NFS also) and recently implemented a new vSphere environment. When one of the hosts was isolated virtual machines were restarted and users started reporting strange problems.

What happened was that the vSphere HA Isolation Response was configured to “Leave Powered On” and as both the Management Network and the iSCSI Network were isolated there was no “datastore heartbeating” and no “network heartbeating”. Because the datastores were unavailable the lock on the VMDKs expired (virtual disk files) and HA would be able to restart the VMs.

Now please note that HA/ESXi will power-off (or kill actually) the “ghosted VM” (the host which runs the VMs that has lost network connection) when it detects the locks cannot be re-acquired. It still means that the time between when the restart happens and the time  when the isolation event is resolved potentially the IP Address and the Mac Address of the VM will pop up on the network. Of course this will only happen when your virtual machine network isn’t isolated, and as you can imagine this is not desired.

When you are running IP based storage, it is highly (!!) recommend to configure the isolation response to: power-off! For more details on configuring the isolation response please read this article which lists the best practices / recommendations.

Datastore Heartbeating and preventing Isolation Events?

I was just listening to some of the VMworld sessions and one was about HA. The presenter had a section about Datastore Heartbeats and mentioned that Datastore Heartbeats was added to prevent “Isolation Events”. I’ve heard multiple people make this statement over the last couple of months and I want to make it absolutely clear that this is NOT true. Let me repeat this, Datastore Heartbeats do not prevent an isolation event from occurring.

Lets explain this a bit more in-depth. What happens when a Host is cut off from the network because its NIC which carries the management traffic has just failed?

1. T0 – Isolation of the host (slave)
2. T10s – Slave enters “election state”
3. T25s – Slave elects itself as master
4. T25s – Slave pings “isolation addresses”
5. T30s – Slave declares itself isolated and “triggers” isolation response

Now as you can see the Datastore Heartbeat mechanism plays no role whatsoever in the process for declaring a host isolated, or does it? No from the perspective of the host which is isolated it does not. The Datastore Heartbeat mechanism is used by the master to determine the state of the unresponsive host. The Datastore Heartbeat mechanism allows the the master to determine if the host which stopped sending network heartbeats is isolated or has failed completely. Depending on the determined state the master will take appropriate action.

To summarize, the datastore heartbeat mechanism has been introduced to allow the master to identify the state of hosts and is not use by the “isolated host” to prevent isolation.

vSphere 5 HA – Isolation Response which one to pick?

Last week I did an article about Datastore Heartbeating and the prevention of the Isolation Response being triggered. Apparently this was an eye-opener for some and I received a whole bunch of follow up questions through twitter and email. I figured it might be good to write-up my recommendations around the Isolation Response. Now I would like to stress that these are my recommendations based on my understanding of the product, not based on my understanding of your environment or SLA. When applying these recommendations always validate them against your requirements and constraints. Another thing I want to point out is that most of these details are part of our book, pick it up… the e-book is cheap.

First of all, I want to explain Isolation Response…

Isolation Response is the action HA triggers, per VM, when it is network isolated from the rest of your cluster. Now note the “per VM”, so a host will trigger the configured isolation response per VM, which could be either “power off” or “shutdown”. However before it will trigger the isolation response, and this is new in 5.0, the host will first validate if a master owns the datastore on which the VMs configuration files are stored. If that is not the case then the host will not trigger the isolation response.

Now lets assume for a second that the host has been network isolated but a master doesn’t own the datastore on which the VMs config files are stored, what happens? Nothing happens. Isolation response will not be triggered as the host knows that there is no master which can restart these VMs, in other words there is no point in powering down a VM when it cannot power it on. The host will of course periodically check if the datastore is claimed by a master.

There’s also a scenario where the complete datastore could be unavailable, in the case of a full network isolation and NFS / iSCSI backed storage for instance. In this scenario the host will power off the VM when it has detected another VM has acquired the lock on the VMDK. It will do this to prevent a so-called split brain scenario, as you don’t want to end up with two instances of your VM running in your environment. Keep in mind that in order to detect this lock the “isolation” on the storage layer needs to be resolved. It can only detect this when it has access to the datastore.

I guess there’s at least a couple of you thinking but what about the scenario where a master is network isolated? Well in that case the master will drop responsibility for those VMs and this will allow the newly elected master to claim them and take action if required.

I hope this clarifies things.

Now lets talk configuration settings. As part of the Isolation Response mechanism there are three ways HA could respond to a network isolation:

1. Leave Powered On – no response at all, leave the VMs powered on when there’s a network isolation
2. Shutdown VM – guest initiated shutdown, clean shutdown
3. Power Off VM – hard stop, equivalent to power cord being pulled out

When to use “Leave Powered On”
This is the default option and more than likely the one that fits your organization best as it will work in most scenarios. When you have a Network Isolation event but retain access to your datastores HA will not respond and your virtual machines will keep running. If both your Network and Storage environment are isolated then HA will recognize this and power-off the VMs when it recognizes the lock on the VMDKs of the VMs have been acquired by other VMs to avoid a split brain scenario as explained above. Please note that in order to recognize the lock has been acquired by another host the “isolated” host will need to be able to access the device again. (The power-off won’t happen before the storage has returned!)

When to use “Shutdown VM”
It is recommend to use this option if it is likely that a host will retain access to the VM datastores when it becomes isolated and you wish HA to restart a VM when the isolation occurs. In this scenario, using shutdown allows the guest OS to shutdown in an orderly manner. Further, since datastore connectivity is likely retained during the isolation, it is unlikely that HA will shut down the VM unless there is a master available to restart it. Note that there is a time out period of 5 minutes by default. If the VM has not been gracefully shutdown after 5 minutes a “Power Off” will be initiated.

When to use “Power Off VM”
It is recommend to use this option if it is likely that a host will lose access to the VM datastores when it becomes isolated and you want HA to immediately restart a VM when this condition occurs. This is a hard stop in contrary to “Shutdown VM” which is a guest initiated shutdown and could take up to 5 minutes.

As stated, Leave Powered On is the default and fits most organizations as it prevents unnecessary responses to a Network Isolation but still takes action when the connection to your storage environment is lost at the same time.