Archive for

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:

Likelihood that host will retain access to VM datastores	Likelihood that host will retain access to VM network	Recommended Isolation policy	Explanation
Likely	Likely	Leave Powered On	VM is running fine so why power it off?
Likely	Unlikely	Either Leave Powered On or Shutdown	Choose shutdown to allow HA to restart VMs on hosts that are not isolated and hence are likely to have access to storage
Unlikely	Likely	Power Off	Use Power Off to avoid having two instances of the same VM on the VM network
Unlikely	Unlikely	Leave Powered On or Power Off	Leave Powered on if the VM can recover from the network/datastore outage if it is not restarted because of the isolation, and Power Off if it likely can’t.

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.