As a cloud architect, I’ve had the opportunity to work with a variety of technologies and solutions, but one of the most fascinating journeys has been my transition from infrastructure administration to cloud architecture. In this blog post, I’ll share my experiences and lessons learned from this journey, specifically focusing on a recent case study that highlights the importance of understanding vSAN stretched cluster design considerations.

Recently, I was working on a project where we had to design a highly available and scalable virtualized infrastructure for a client. We decided to use vSAN as our storage solution, and after researching and testing different configurations, we settled on a stretched cluster design. However, during the implementation phase, we encountered an issue that made us question the limitations of this design.

The issue arose when one of the hosts in the cluster became unresponsive and disconnected from the vCenter server. We tried to add a new witness host to replace the failed host, but found that we were unable to do so due to a limitation in vSAN’s design. Specifically, vSAN requires all hosts to be connected to the vCenter server before initiating reconfiguration operations, such as adding or removing witness hosts.

This limitation is intended to ensure that vSAN collects enough information from all hosts before initiating any changes, which helps prevent data corruption and ensures a smooth upgrade process. However, in our case, this limitation became a problem because we were unable to replace the failed host with a new witness host until the unresponsive host was brought back online.

At first, we thought this was a major issue that could potentially cause downtime and affect the availability of our infrastructure. However, after further research and testing, we discovered that vSAN can still rebuild data on other hosts even if one host is not responding. This means that we can still maintain the high availability and scalability of our infrastructure, even in the event of a host failure.

While this was a relief, it also raised some questions about why anyone would want to change witness hosts exactly when a host is not responding. After all, if a host is not available, vSAN will rebuild data on other hosts anyway, so why bother changing the witness host at that time? The answer lies in the fact that sometimes, maintenance and upgrades are unavoidable, and having the ability to change witness hosts during these times can be beneficial.

For example, if a host is scheduled for an upgrade or maintenance, it would be wise to change the witness host before the maintenance window begins. This ensures that the cluster remains highly available and scalable even during the maintenance period. Additionally, having the ability to change witness hosts as needed can help improve the overall reliability and availability of the infrastructure.

So, what’s the takeaway from this case study? The most important lesson I learned is the importance of understanding vSAN stretched cluster design considerations before implementing such a solution. While vSAN offers many benefits, such as high availability and scalability, it also has limitations that must be considered when designing and implementing a highly available infrastructure.

In conclusion, my journey from infrastructure administration to cloud architecture has been a rewarding one, filled with opportunities to learn and grow. The case study of our experience with vSAN stretched cluster design considerations highlights the importance of understanding the limitations and capabilities of storage solutions like vSAN. By doing so, we can design and implement highly available and scalable infrastructures that meet our clients’ needs and provide a solid foundation for their businesses.