The whole cluster is dead? How did that happen? Worst case in an "all down" you boot up the first few ESXi hosts, direct connect in with the VIClient, import a DC (if needed..or find it), boot it up. Set it to auto boot. Same stuff you'd do with a virtual vCenter.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
VMware proper cloud datastores
- Thread starter loudsnare
- Start date
The whole cluster is dead? How did that happen? Worst case in an "all down" you boot up the first few ESXi hosts, direct connect in with the VIClient, import a DC (if needed..or find it), boot it up. Set it to auto boot. Same stuff you'd do with a virtual vCenter.
MrGuvernment
Fully [H]
- Joined
- Aug 3, 2004
- Messages
- 21,823
tons of good info here, Virtualizing our office as well and good to know info here.
RiDDLeRThC
2[H]4U
- Joined
- Jun 13, 2002
- Messages
- 3,963
I'm sure others do this but we keep vCenter and DC1 locked to ESX01, DC2 on ESX2. Just incase we have a total failure I know where to find them.
huh? What kind of clustering are you thinking about?
ESXi clusters are all independent hosts. Pick a host, start booting stuff.
Are you talking about a whole blade enclosure failing or a bunch of individual servers losing power or something of the likes?
Redundancy is key with all of this, from power, network, storage paths/processors, etc. There shouldn't be too many scenarios where a whole cluster can just die. If your ESX hosts are in a blade cluster then you may want to have your vSphere clusters divided up by groups of servers in different physical enclosures so you can at least provide HA.
This is a very heated debate, but personally I like the idea of management clusters in large environments. Just take two hosts and have your critical management services run there. I've seen VCDX's argue this one back and forth, but there is a compromise between complexity and comfort that each person must consider in their design.
Also in a pinch you can connect to every ESXi host in the cluster via PowerCLI to quickly find where your vCenter is located if it didn't either power on or the vCenter Server service didn't start
Code:
>Connect-VIServer -Server 192.168.1.2, 192.168.1.3, <etc> -User root -Password "<password>"
Get-VM <vcenter server name> | flFrom there it will return which host it is currently sitting on
I run a physical AD server... I wouldn't be afraid to run both on my vSphere cluster but I sure as shit wouldn't run them both on a single SAN again.
We had a good 4 hours of total darkness because we had a SAN totally crap out (single controller failure brought down the "N+1" SAN), vendor was completely useless, found out the hard way the write-cache vanishes upon reboot, sucks pretty bad when you're running your AD, DNS, DHCP, Mail, etc all off the SAN.
And yes, it was a "certified" vendor. Not a big player, but they have a booth at VMworld.
We had a good 4 hours of total darkness because we had a SAN totally crap out (single controller failure brought down the "N+1" SAN), vendor was completely useless, found out the hard way the write-cache vanishes upon reboot, sucks pretty bad when you're running your AD, DNS, DHCP, Mail, etc all off the SAN.
And yes, it was a "certified" vendor. Not a big player, but they have a booth at VMworld.
I'll state something everyone else is afraid to say.
Hardware can fail in an infinite number of ways. Sure, if a component goes totally "dark" you can program for that, but there are an infinite number of other ways it can start going "wrong" and not die totally, or die in a way that wasn't considered. You're trying to program for an infinite set there, and that's not possible to solve. All you can do is account for as many failure states as possible, and keep improving. This is true for ~any~ vendor.
Exactly. I've said exactly that to many customers who try to protect against ANY possible scenario. It's not worth it. You have to make too many compromises to do it. You have to be realistic.
Going through some of the vSphere Design material and training now. Every author of the material i've read states exactly what lopoetve and Netjunkie have said. You have to accept that you can not build an environment that provides 100% protection.
Most of the time it's too damn expensive. On top of that, you should look at the common things that do fail, IE server, Disk, network, power. It's fairly easy to accomodate for some of those things because vendors are providing that protection as a standard practice, however it's not infallible.
But it's not just about those things with vSphere. It's also about how you configure vSphere as well. You can have all the redundancy in the world, but a poorly configured vSphere environment could mean certain failure and problems. I tend to look at this as more of a risk than the actual hardware failing.
It's funny, when I first started out with VMware vSphere and read the Mastering vSphere books, took the exams. got some solid years of real world experience..yada yada, I thought I had a solid grasp. Only now, going through the DCD training material, and Design books do I realize that it's much more complex especially when you throw in the many, and I mean thousands of scenarios that you could face.
There are a few glaring points that i've taken from my studying and training in design so far:
1. A good vsphere design will mitigate risk for the person/person's that will be supporting it.
2. Keep it as simple as possible as too much complexity also introduces risk as well.
3. A good design makes it harder for the support team to make human error.
Most of the time it's too damn expensive. On top of that, you should look at the common things that do fail, IE server, Disk, network, power. It's fairly easy to accomodate for some of those things because vendors are providing that protection as a standard practice, however it's not infallible.
But it's not just about those things with vSphere. It's also about how you configure vSphere as well. You can have all the redundancy in the world, but a poorly configured vSphere environment could mean certain failure and problems. I tend to look at this as more of a risk than the actual hardware failing.
It's funny, when I first started out with VMware vSphere and read the Mastering vSphere books, took the exams. got some solid years of real world experience..yada yada, I thought I had a solid grasp. Only now, going through the DCD training material, and Design books do I realize that it's much more complex especially when you throw in the many, and I mean thousands of scenarios that you could face.
There are a few glaring points that i've taken from my studying and training in design so far:
1. A good vsphere design will mitigate risk for the person/person's that will be supporting it.
2. Keep it as simple as possible as too much complexity also introduces risk as well.
3. A good design makes it harder for the support team to make human error.
Last edited:
^ agreed!
Definitely read Scott Lowe's vSphere Design book. He definitely covers many of the typical design scenarios and what the tradeoff's are of each. Definitely makes you think. If you find that stuff fun then take the DCD exam. Although very long, it's the most fun I've ever had taking an exam.
Definitely read Scott Lowe's vSphere Design book. He definitely covers many of the typical design scenarios and what the tradeoff's are of each. Definitely makes you think. If you find that stuff fun then take the DCD exam. Although very long, it's the most fun I've ever had taking an exam.
Because some people prefer block storage. Because transport type doesn't really matter either, and they all cost about the same these days to be honest.
QFT. "Realistic" though is going to vary depending on what type of availability you need (and your budget). Three Nines is very different from Five Nines in terms of architecting fallback/recovery scenarios.
And that's what I mean by realistic. For some reason the people with $ always want more than the people with $$$ want...they seem to be more realistic.
so, wrench, instead of learning to properly use a tool in your bag you're just going to throw it away?
interesting
screw the scenarios you have to be able to cut the check with the additional digits to the left of the decimal first. five 9s can get real expensive.
To a degree I'm with wrench. People sometimes try and "force" iSCSI when something like NFS would do the job better. Better array integration in many cases..simpler...and doesn't have some limitations like 8-host limit w/ linked clones.
handing off iscsi to a colo cab is much simpler.
depending on your stack, replicating block over the network can be simpler with iscsi as well. i forget if SRM works with NFS stores or not but as an example cloudstack has built in replication for iscsi ... not positive it cant work with nfs or not.
just sayin, iscsi has its place. vmware's nfs client still sucks too. wtb v4. want to disable sync (selectively). etc.
depending on your stack, replicating block over the network can be simpler with iscsi as well. i forget if SRM works with NFS stores or not but as an example cloudstack has built in replication for iscsi ... not positive it cant work with nfs or not.
just sayin, iscsi has its place. vmware's nfs client still sucks too. wtb v4. want to disable sync (selectively). etc.
I'm not sure more than 8 hosts on a VMDK tree is supported with NFS, I'll have to check with someone else. The technical limitation isn't there, but there are other limits too.
The cases for justifying iSCSI over NFS now are getting slim. madrebel, you remind me of myself in a time really all not too long ago. I'm not sure if you're holding on to iSCSI due to the unknown but at bare minimum it's worth trying out in a sandbox to see if it works for you.
Yes, SRM supports NFS.
It is..that's one way (well..THE way) around the limit with vCloud Director and linked clones. Need more than 8 hosts in a resource cluster? Use NFS.
Isn't NFS required for vCloud Director for some purpose..I can't recall...grrr..have to go back to the white papers? I'm not saying it's a requirement for the vApps but I seem to recall there is something requiring an NFS share.
I use all NFS with my Home Lab running VCD 1.5.
I use all NFS with my Home Lab running VCD 1.5.
It is for ISO files on the vCloud cell.
im in a shared environment. i can extend a vlan down to a port and run nfs no problem but when someone requests iscsi i can't just say "hey go fuck yourself nfs is just as good". people want what they want.
Of course, those are standard political obstacles. I once pushed back from NFS due to lack of education myself. As long as you know the trade offs and benefits of each then that's all that really matters.
SRM only serializes lock removal on NFS - prepping storage takes significantly longer than VMFS.
There's also better statistics on iSCSI vs NFS, since it's scsi the whole way through, instead of a file share. It can also be multipathed easier, for better load balancing between controller heads for an array, although that doesn't matter that much. Failover is native in the scsi land, instead of network based too, which can be a plus.
Both have advantages and disadvantages that will never go away.