In my opinion, one of the best features within the 6.5 vCenter Server Appliance is the ability to perform backups from the appliance itself (natively). No agents, snapshots or scripts required. It really is quite simple, and I’m glad VMware added this additional feature. How many times have you heard someone explain the importance of backups?
Before building out your vSAN cluster, one thing that you should be conscious of is that of maintenance activities. Some time ago, someone told me “Anyone can make something work, but few take the time to think of the long term implications (years from now) of setting things up a certain way”.
Introduction to VM Storage Policies
One of the great features within vCenter is the ability to create VM Storage Policies. What are VM Storage Policies?
According to VMware Official documentation, VM Storage policies are specific requirements placed upon underlying storage to ensure desired characteristics are met.
One of the most powerful technologies today in Storage is a feature called Deduplication. Deduplication is technology that references data once instead of multiple times. This allows for insane Data Reduction. For instance, if you had 600GB of data with a 6:1 Dedup ratio, only 100GB would actually be stored! Dedupe within vSAN is done on 4KB Block level.
On Monday’s post, I did a quick blog on how easy it was to enable vSAN within vCenter. vSAN, as it was discussed in earlier posts, is a very powerful tool that utilizes software defined storage at the hypervisor level, which reduces costs and complexity. Storage is the key ingredient to this solution, so we may need to add disk in order to actually utilize vSAN right? Fortunately, VMware (like most things with vSAN) has made this process incredibly simple. Today’s blog is a continuation from Monday’s blog, which will show us how easy it is to claim disk for vSAN usage. Disk claiming is needed in order build out your vSAN datastore. This is what makes vSAN so different from traditional hosts/storage configurations.
Last week I wrote a detailed post last week on vSAN. Now that vSAN has been explained and the benefits understood, let’s get started with how to enable it within a lab setting.
Note: This is a quick blog on how to enable vSAN, which will be part of a larger mini series that will take us through each step. It’s primary purpose is to show how easy it is to enable vSAN. With that said, vSAN shouldn’t be enabled within a production environment without proper planning, consideration, and change controls. While vSAN is something you can enable with the “flip of a switch”, it doesn’t mean you should. Careful consideration should be taken while planning. Performance is something else that you should keep in mind. If all possible, engage the help of a vSAN resource that can guide you through the process. This isn’t something to be taken lightly, and caution should be taken when designing your vSAN deployment. Finally, the VMware Hardware Compatibility Guide should always be used.
Without referencing this, you can quickly set yourself up for failure. With that said, always reference the compatibility guide religiously!
Today’s blog post is all about vSAN. vSAN, according to VMware, is VMware’s hyper-converged software solution. In order to understand the differences between hyper-converged and software defined, let’s look at the definition for each. With all of the cool/hip buzz words, there is a lot of misunderstandings, and often times these words are interchangeably used without understanding the terminology correctly.