If you haven’t seen it yet, you can pick up the vSAN 6.7 U1 Deep Dive ebook for 4.99 USD and the paper copy for 19.99. Yes, we also lowered the price for all other regions, so it doesn’t matter where you are, you should able to pick it for less than a Big Mac meal! Although the book doesn’t cover vSAN 7.0, we still feel it is very relevant, and all core principles still apply to vSAN today. Hopefully, we will be able to update the book at some point later this year, if and when we can find the time, for now hopefully this offer makes the book affordable all over the world!
I had a question this week around the failure of a host. The question was how long it takes before a host is declared failed. Now let’s be clear, failed means “dead” in this case, not isolated or partitioned. It could be the power has failed, the host has gone completely unresponsive, or anything else where there’s absolutely no response from the host whatsoever. In that scenario, how long does it take before HA has declared the VM dead? Now note, the below timeline is in a traditional infrastructure. Also note, that this is theoretical, when everything is optimal.
- T0 – Secondary Host failure.
- T3s – The Primary Host begins monitoring datastore heartbeats for 15 seconds.
- T10s – The host is declared unreachable and the Primary will ping the management network of the failed host.
- This is a continuous ping for 5 seconds.
- T15s – If no heartbeat datastores are configured, the host will be declared dead.
- T18s – If heartbeat datastores are configured and there have been no heartbeats, the host will be declared dead, restarts will be initiated.
Now, when a Primary Host fails the timeline looks a bit different. This is mainly because first, a new Primary Host will need to be elected. Also, we need to ensure that the new primary has received the latest state of all secondary hosts.
- T0 – Primary Host failure.
- T10s – Primary election process initiated.
- T25s – New primary elected and reads the protectedlist.
- New primary waits for secondary hosts to report running VMs
- T35s – Old primary declared unreachable.
- T50s – Old primary declared dead, new primary initiates restarts for all VMs on the protectedlist which are not running.
Keep in mind, this does not mean that VMs will be restarted with 18 seconds, or 35 seconds, for that matter. When the host is declared dead, or a new primary is elected, the restart process starts. The VMs that need to be restarted will first need to be placed, and when placed, they will need to be restarted. All of these steps will take time. On top of that, depending on the operating system and the apps running within the VM, the time it takes before the restart is fully completed could vary a lot between VMs. In other words, although the state is declared rather fast, the actual total time it takes to restart can vary and is definitely not an exact science.
I posted this thread on Twitter and Linkedin, and I figured I would cross-post it here as well, as it makes it easier to find whenever I need to point someone to it. I get this question still once every quarter at least: I started blogging, podcasting, and/or a channel on youtube, how do I grow my audience? It seems that everyone is always looking for that magic formula. But there really isn’t a formula if you ask me. There are a couple of things that will help to grow your blog/podcast/channel or social profile/following though.
First and foremost: content and authenticity! You need to make sure you are passionate about the topic, and of course that it is a topic that others are interested in. if you are not passionate then that will stand out in your content, and if others are not interested in the topic of course views will be relatively low. The content will also need to be delivered in an authentic way, whether that is in writing or recording.
Then there’s consistency and perseverance. You don’t need to post every day, but there needs to be some kind of consistency in terms of content publishing. Once a week, three times a week, twice a month. Keep going, even if you don’t see the numbers going up. This is what definitely helped me grow my blog readership in the early days. I had a goal of one update a week, but don’t force it. If there’s nothing to post, don’t post…
Then there’s timing. If you want to capture views from social media channels, you will want to post the content around the time most people will click it, or see it. As things like RSS readers are pretty much dead, two things will drive your views: social media and search engines. So make sure to pick a day/time where you feel you would get the most traction (look at your stats).
That leads me to the next thing, search engines. Make sure you optimize your content (title, body, keywords, images, video) and platform (wordpress etc) for search engines. Most blogs these days, as an example, will get their views via Google. If Google doesn’t rank you high enough… I guess that speaks for itself right. Most platforms also have plugins to optimize your blog for you, and of course, with youtube/podcasts your shownotes/description and title are absolutely key!
Then there are the social channels. Make sure to grow these organically. Be active on the various platforms, be responsive. Don’t overdo it, don’t try to stand out, but try to be helpful instead! People appreciate the responsiveness, people appreciate the help. Even though my inbox/DMs are swamped at times, I always aim to reply to everyone. Not only reply, but I have a few search columns open on twitter always, if I know the answer to a question I will reply. This not only helps you grow your following, but it also helps with finding new topics for content!
The last thing I want to mention, be unique in terms of content. There’s no point in being blog number 78 sharing release notes. Look for that detail and try to elaborate on it. Dig deeper. Whether it is a blog, a video, or a podcast. People appreciate unique solid content! That is why they will follow you, that is why they will return to your blog or subscribe to your channel or podcast.
Sometimes unfortunately there are situations where a vendor’s ESXi image includes a disk controller driver that is not on the vSAN HCL/VCG (VMware Compatibility Guide). Typically it is a new version of the driver which is supported for vSphere, but not yet for vSAN. In that situation, what should you do? So far there are two approaches I have seen customers take:
- Keep running with the included driver and wait for the driver to be supported and listed on the vSAN HCL/VCG
- Downgrade the driver to the version which is listed on the vSAN HCL/VCG
Personally, I feel that option 2 is the correct way to go. The reason is simple, vSphere and vSAN have different certification requirements for disk controllers and the vSAN certification criteria are just more stringent than vSphere’s. Hence, sometimes you see vSAN skipping certain versions of drivers, this usually means a version did not pass the tests. Now, of course, you could keep running the driver and wait for it to appear on the vSAN HCL/VC. If however, you hit a problem, VMware Support will always ask you first to bring the environment to a fully supported state. Personally, I would not want the extra stress while troubleshooting. But that is my experience and preference. Just to be clear, from a VMware stance, there’s only one option, and that is option two, downgrade to the supported version!
I had this question last week around vSAN 2-node direct connect and whether using a crossover cable is still required to be used or if a regular CAT6 cable (CAT 5E works as well) can be used. I knew the answer and figured this would be documented somewhere, but it doesn’t appear to be. To be honest, many websites when talking about the need for crossover cables are blatantly wrong. And yes, I also spotted some incorrect recommendations in VMware’s own documentation, so I requested those entries to be updated. Just to be clear, with vSAN 2-Node Direct Connect, or vMotion, or any other service for that matter, you can use a regular CAT6 cable, combined with 10GbE (or faster) NICs, this gives you great performance without the cost of a 10GbE (or faster) switch. I can’t recall having seen a NIC in the past 10 years that does not have Auto MDI/MDI-X implemented, even though it was an optional feature in the 1000Base-T standard. In other words, there’s no need to buy a crossover cable, or make one, just use a regular cable.