Admission Control has long been a misunderstood and often improperly used feature, and in my opinion, is overdue for an overhaul. The last of the big new HA features is a usability improvement focusing around Admission Control. This can also utilize a new status called Quarantine Mode, which keeps VMs from starting on this host unless absolutely necessary (or you can use a more traditional Maintenance Mode, which won’t put any VMs on the host no matter what). This event will actually use vMotion to migrate the VMs (similar to putting a host into Maintenance Mode), thus preventing any downtime at all. I can see definite use cases with this when it comes to things like SMART data from hard drives, flaky DIMMs, or even something like an overheating chassis. This is a third-party-dependent feature that enables hardware vendors to inform vSphere of potential issues with a host and trigger an HA event before the host actually begins showing signs of an issue. This helps make failure events more predictable, and predictability is a great thing! Setting VM Restart OrderĪlso in the HA realm of upgrades, vSphere now has a new checkbox called Proactive HA. With 6.5, HA can bring up servers in a specific order (think vApps, SRM, or Zerto) after an HA event has occurred. Unfortunately, while vSphere has traditionally had a very rudimentary VM Restart Priority, it doesn’t actually orchestrate any servers as they relate to each other. Well, what if those three servers were all on the same physical host, and that host failed? Currently, HA will restart all three servers on different hosts. If you were to cold boot this app, you would probably have an order to the VMs to bring up, right? Usually it is something like Database first, then Application, and finally Web. Consider this: Three servers (Database, Application, and Web) all service the same logical app.
One basic feature that is long overdue is the ability to set a restart order for an HA event. Redundancy of the Future: Orchestrated HA, Proactive HA, and Admission Control Orchestrated HA While all of this vCenter stuff is great, what about improvements to normal VMs and workloads? VMware has made several improvements to their oldest feature in the book: High Availability.
Given that things are becoming faster and more automated as a whole (and such automation would use vCenter to complete tasks), this is more important than ever to implement in modern environments. VCenter HA will go a long way in ensuring even higher uptime for vCenter. The Witness, as you can probably guess, is there to prevent split-brain scenarios (which sounds a lot cooler than it is in practice). This is an Active/Passive configuration that uses a back-end network to replicate the vPostgres data between the Active, Passive, and Witness appliances. It basically allows you to cluster multiple vCenters that are responsible for the same environment.
#Ha and drs with vcenter 6.5 windows#
This is a VCSA-only technology (not surprising given VMware’s desire to move away from the Windows vCenter Server). With 6.5, VMware offers a new way of ensuring high uptime for vCenter itself: VCSA High Availability. vCenter Heartbeat was the old way of doing this, but that product is no longer offered by VMware. While technologies like HA are designed to function without vCenter being available, many deployments (including SCTG’s Enterprise Cloud) need very high uptime for vCenter just to carry out day-to-day activities. After all, vCenter itself can be a single point of failure in many environments. One of the big issues that many customers face when deploying vCenter is related to availability. One thing I like about vSphere 6.5 is that there are features that every vSphere environment, big or small, simple or complex, can use.
0 kommentar(er)
