After about a month of preparation, I was able to successful sit Amazon’s AWS Cloud Practitioner exam. This is the first of many that I hope to obtain. I was unable to obtain the AWS Solutions Architect Associate at first go, so I regrouped and took this foundation course in hopes that it would boost my knowledge and reinvigorate my desire to pass the AWS Solutions Architect Associate exam. The exam was a good overview of the offerings AWS has to offer. I highly recommend it for anyone looking to dip their toe in AWS.
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.
Finalizing this month’s series on data protection, I wanted to follow up last week’s blog post on installing Avamar Virtual Edition with this one, which is installing Data Domain Virtual Edition. The two are often married together in Data Protection deployments. Simply put, Avamar is the front end backup engine that has all of backup software, and DataDomain is the landing spot for the backup data. DataDomain is Dell EMC’s appliance based deduplication device. It is the market leader in purpose-built backup appliances. Various workloads can be ingested, including data from Avamar, VEEAM, Networker, etc. Like the Avamar VE, DataDomain VE allows you fully take advantage of virtualization in one easy to manage package. The virtual edition is geared towards small-to-medium size environments and/or EDGE locations (ROBO). With that said, let’s get started!
Be sure to check out the system requirements before you proceed.
Dell EMC easily allows anyone to give DataDomain VE a try. To get started, first download the trial copy by heading over to Dell EMC’s website.
In the upper right hand corner, select download for the VMware 0.5TB Try and Buy.
The download file should start downloading
On yesterday’s blog, I was able to deploy Avamar Virtual Edition. One of the goals once deployed was to test integration with vCenter 6.5; however, when I attempted to add my test 6.5 vCenter server, I received an error. The error states “Failed to communicate to vCenter. Unable to find a valid certification path to the vCenter”.
This is caused since I don’t have a certificate installed on my test vCenter server. So, with that said, here’s what I did to resolve the issue.
Using WinSCP, connect to your Avamar node and navigate to the following directory.
/usr/local/avamar/var/mc/server_data/prefs then double click mcserver.xml
Locate vmware within the XML file. Within the entry keys, locate “ignore_vc_cert value=false”
Change the value from “false” to“true”. This resolves the issue by telling Avamar to ignore the requirement for a certificate.
Once the change has been made, click save in the upper left hand corner of WinSCP. Now we need to start/stop the MCS in order for the changes to take.
To do this, putty into the Avamar node as admin and run dpnctl stop mcs
Once the MCS is shutdown, start the MCS by running dpnctl start mcs
Now that the MCS has restarted successfully, you can login back into the Avamar GUI to add the vCenter server as a client.
In order to complete this, click on the Administration tab, then click the Account Management tab. Next, locate the top level domain, right click and select new client.
Enter the vCenter server credentials and click “OK“.
Once authenticated, the vCenter server is now seen as a client. You can now add VMs for backups.