A post two days in a row? This is some sort of record. In any case today we're going to discuss the small and not best practices friendly test environment I set up here at 3X. The reason the cluster exists is that we had to adjust the product to suit the needs of a customer who has a SQL cluster, and as such we needed a test environment with which to pound on incessantly to make sure it worked. I'll very quickly detail what went into it, and then describe how it is being backed up by 3X Appliance.
Here is a list of the things needed in order to set it up:
1. 2 VMs running Windows Server 2008 R2 Enterprise or Datacenter (Mine are datacenter)
2. 1 VM running a virtual NAS device to act as shared storage (FreeNAS for me)
3. Windows domain
4. Backup appliance
So the list of parts is pretty simple. In my instance I have a VM set up on one of our hyper-v test hosts, and another set up on my test ESXi host (I do enjoy the mixed environment). The first step I had to complete after getting the operating system set up for both VMs and getting them on the domain properly was to install the failover cluster feature. It's a straight forward process just like any other Windows Server feature install and I merely followed the wizard as it lead the way.
Now before you set up the actual cluster you have to make sure there is some sort of shared storage setup. Now Windows Server requires Persistent Reservations to be enabled on this storage so you can't use OpenFiler in order to simulate the NAS. After some digging around I did find out that FreeNAS supports said feature.You can follow the instructions here in order to set up an appliance to run the FreeNAS software (unless of course you are lucky enough to have a NAS already). And these instructions are helpful for setting up the iSCSI target you'll need to use as the shared storage. After FreeNAS is set up right you'll just need to use the Microsoft iSCSI initiator to get the LUN exposed to your VMs. You must do this on all VMs you are adding to the cluster in order for it to work properly.
Next you'll need to go into your snap in console and to the Clustering management portion in order to actually create the cluster. Again this is merely a matter of going through a few wizard windows, but as long as you have all the prerequisites set up properly you shouldn't have any trouble.Once complete you'll have a lovely two or more node cluster for your testing/enjoyment. Pay particular attention to the validation step for the wizard as it's very good at telling you all the things you forgot to do, or did wrong. One thing I should note here is that you should never use a two node cluster for production. If one of the nodes fails the whole thing goes down and you lose quorum. At minimum you should have 3 nodes for a production environment.
Now on to backing it up. Since I work at 3X and have access to their appliances I use one of them to backup the evironment. I have a SQL level and a file level backup taking place for this cluster. Now there is something critical to keep in mind if you are using an agent based backup like ours to backup a cluster and that is the ownership of the LUN(s) you are using for shared storage. In my example I have sqlcluster01 and sqlcluster02.
As you can see from the screenshot my disk is owned by sqlcluster02. So the only way I'm going to get a file level back up of this volume is if I have the agent installed on that VM. Once this is achieved you'll see the drive show up as any other in our wizard as below:
So file level backup is pretty straight forward, but what about SQL? Well for 3X as of version 3.1.25 you can backup SQL clusters and you do so just like any other SQL instance. You just install the agent on the production node and set up a SQL job as per the instructions you can find here under Administrative Guide > Creating Backups.
That's the summary of things. I am of course always available for any feed back or questions which you can leave either in the comments or you can email me directly via the address in my signature block below.
Ryan Koch
3X Systems
ryan.koch@3x.com
Here is a list of the things needed in order to set it up:
1. 2 VMs running Windows Server 2008 R2 Enterprise or Datacenter (Mine are datacenter)
2. 1 VM running a virtual NAS device to act as shared storage (FreeNAS for me)
3. Windows domain
4. Backup appliance
So the list of parts is pretty simple. In my instance I have a VM set up on one of our hyper-v test hosts, and another set up on my test ESXi host (I do enjoy the mixed environment). The first step I had to complete after getting the operating system set up for both VMs and getting them on the domain properly was to install the failover cluster feature. It's a straight forward process just like any other Windows Server feature install and I merely followed the wizard as it lead the way.
Now before you set up the actual cluster you have to make sure there is some sort of shared storage setup. Now Windows Server requires Persistent Reservations to be enabled on this storage so you can't use OpenFiler in order to simulate the NAS. After some digging around I did find out that FreeNAS supports said feature.You can follow the instructions here in order to set up an appliance to run the FreeNAS software (unless of course you are lucky enough to have a NAS already). And these instructions are helpful for setting up the iSCSI target you'll need to use as the shared storage. After FreeNAS is set up right you'll just need to use the Microsoft iSCSI initiator to get the LUN exposed to your VMs. You must do this on all VMs you are adding to the cluster in order for it to work properly.
Next you'll need to go into your snap in console and to the Clustering management portion in order to actually create the cluster. Again this is merely a matter of going through a few wizard windows, but as long as you have all the prerequisites set up properly you shouldn't have any trouble.Once complete you'll have a lovely two or more node cluster for your testing/enjoyment. Pay particular attention to the validation step for the wizard as it's very good at telling you all the things you forgot to do, or did wrong. One thing I should note here is that you should never use a two node cluster for production. If one of the nodes fails the whole thing goes down and you lose quorum. At minimum you should have 3 nodes for a production environment.
Now on to backing it up. Since I work at 3X and have access to their appliances I use one of them to backup the evironment. I have a SQL level and a file level backup taking place for this cluster. Now there is something critical to keep in mind if you are using an agent based backup like ours to backup a cluster and that is the ownership of the LUN(s) you are using for shared storage. In my example I have sqlcluster01 and sqlcluster02.
As you can see from the screenshot my disk is owned by sqlcluster02. So the only way I'm going to get a file level back up of this volume is if I have the agent installed on that VM. Once this is achieved you'll see the drive show up as any other in our wizard as below:
So file level backup is pretty straight forward, but what about SQL? Well for 3X as of version 3.1.25 you can backup SQL clusters and you do so just like any other SQL instance. You just install the agent on the production node and set up a SQL job as per the instructions you can find here under Administrative Guide > Creating Backups.
That's the summary of things. I am of course always available for any feed back or questions which you can leave either in the comments or you can email me directly via the address in my signature block below.
Ryan Koch
3X Systems
ryan.koch@3x.com
No comments:
Post a Comment