Re: Large fileserver on VMware design questions
Remco, According to http://www-01.ibm.com/support/docview.wss?rs=0uid=swg21053218 the client 6.2 is supported in a 5.5. server environment. Mvg/regards, Paul -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: donderdag 24 juni 2010 7:54 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Large fileserver on VMware design questions snip Yes, TSM client 6.2 is not supported with the 5.5 server ;-)
Ang: Large fileserver on VMware design questions
Hi there I'm not sure how many files you will be holding in this fileserver cluster, but at some point you will reach a soft limit where inspecting the files will take to long for the backup to be done within a reasonable amount of time. Another way of approaching large fileservers and the issues concerning backups are using the FastBack client instead of the normal TSM client. Since FastBack utilizies VSS snapshots by default, and only does bitlevel incremental backups, there is no need for inspection of files. This will seriously lower the amount of time needed to perform an incremental backup. With FB you wont have the need to do any additional VSS snapshots to lower the restore time so that will eliminate the need to do different solutions to assure restore times are as short as possible. Another positive effect of using the FastBack client is that the time-to-data in case of a restore will be quite short, due to the way FB mounts the backup image and lets users access this directly. That means that as soon as you start the restore of the filesystem, the files are immediatly accessible by your users (even though they havent actually been restored to the filesystem). FB also has the CDP feature (Continous Data Protection) which might be something you'd like to use if we're looking at a large number of changed files on a daily basis (the issue with fileservers are normally that you only back it up once a day, thus loosing data since the last backup made on a restore event). Best Regards Daniel Sparrman -ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU skrev: - Till: ADSM-L@VM.MARIST.EDU Från: Steve Harris st...@stevenharris.info Sänt av: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Datum: 06/24/2010 02:25 Ärende: Large fileserver on VMware design questions Hi gang One of my customers is implementing a consolidated fileserver. This will run in a two way MSCS Cluster. At the moment they are looking at one big filesystem though I will strenuously attempt to dissuade them from that course. Each machine in the cluster is a VM based on a different VMware physical server, running windows 2008 r2 64 bit. TSM client will run on the VMs. My proposed strategy is: - Daily incremental. With journalling. Standard cluster setup with one scheduler for each machine and one for the cluster resource. Journal database resides on the cluster disk. - Weekly VCB image of the cluster disk(s) to enable fast restore after disk failure. - Monthly incremental. Since journalling can't be used on more than one node-name, the monthly incremental will take days and is run by a separate scheduler in the cluster as follows:- -- VSS snapshot of the cluster disk is mounted -- backup is taken -- snapshot is deleted. -- NB VSS snaphots are machine-specific so a failover kills this Questions - Most changing documents are word/excel/powerpoint. Is subfile backup a good fit here on the daily client? What about overhead? - How does one handle the possibility of failover when taking the VCB image? The volume may be mounted on the other VM - can anybody help with scripts for the monthly VSS snapshot backup? Other than the one large filesystem issue is there any obvious flaw in my strategy? TSM Server is 5.5, I will install the 6.2.1 client but this server won't be upgraded for a while. Thanks for your input Steve. Steven Harris TSM Admin Paraparaumu NZ
Re: Large fileserver on VMware design questions
On 24 jun 2010, at 11:40, Paul van Dongen wrote: Remco, According to http://www-01.ibm.com/support/docview.wss?rs=0uid=swg21053218 the client 6.2 is supported in a 5.5. server environment. great, I've misread that, I guess, thanks. I could claim that the doc changed since I've last read it, but I think I'd be lying. Mvg/regards, Paul -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Large fileserver on VMware design questions
I agree with Remco regarding the use of MSCS clusters in a VMWare environment. We currently have an MSCS fileserver cluster on physical machines, but we are debating moving to multiple, smaller vm's (or a single filer, as per my previous post - although all the drawbacks of NDMP that everyone has pointed out certainly makes me nervous). If we do go vm, we have debated whether the extra hassle of MS clustering buys us anything. Right now, the feeling is that clustering only protects against physical problems, which are obviated by using VMWare. Plus my understanding is that in order to run clustering in a supported configuration, the vm's have to use raw disks, which means VCB backups are out the window. -steve schaub -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: Thursday, June 24, 2010 1:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Large fileserver on VMware design questions On 24 jun 2010, at 02:25, Steve Harris wrote: Hi gang One of my customers is implementing a consolidated fileserver. This will run in a two way MSCS Cluster. At the moment they are looking at one big filesystem though I will strenuously attempt to dissuade them from that course. Each machine in the cluster is a VM based on a different VMware physical server, running windows 2008 r2 64 bit. TSM client will run on the VMs. If they're going to use VMWare, why use a windows cluster. Can't they achieve the same with VMWare? My proposed strategy is: - Daily incremental. With journalling. Standard cluster setup with one scheduler for each machine and one for the cluster resource. Journal database resides on the cluster disk. Makes sense. But, I'm now assuming that the individual machines disks are fairly static, so why bother with the TSM incremental backups, and not live by weekly VCB backups alone for those? If you run in a cluster, there are some tweaks to the journal service to just trust the journal DB, rather than purge it in case of a fail-over. - Weekly VCB image of the cluster disk(s) to enable fast restore after disk failure. can do. - Monthly incremental. Since journalling can't be used on more than one node-name, the monthly incremental will take days and is run by a separate scheduler in the cluster as follows:- -- VSS snapshot of the cluster disk is mounted -- backup is taken -- snapshot is deleted. -- NB VSS snaphots are machine-specific so a failover kills this why? Use journaling for the cluster disks, with a dedicated hostname for the cluster. It might be a good idea to run a normal incremental once in a while, esp. if you don't do a normal incremental after a cluster failover. Questions - Most changing documents are word/excel/powerpoint. Is subfile backup a good fit here on the daily client? What about overhead? subfile incremetals are very useful for clients with 28k8 modem connections. I wouldn't bother in a normal data center environment with plenty of bandwidth. - How does one handle the possibility of failover when taking the VCB image? The volume may be mounted on the other VM - can anybody help with scripts for the monthly VSS snapshot backup? Other than the one large filesystem issue is there any obvious flaw in my strategy? Yes, TSM client 6.2 is not supported with the 5.5 server ;-) TSM Server is 5.5, I will install the 6.2.1 client but this server won't be upgraded for a while. Thanks for your input Steve. Steven Harris TSM Admin Paraparaumu NZ -- Met vriendelijke groeten/Kind regards, Remco Post - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
Re: Large fileserver on VMware design questions
Have you looked at using the new VDR appliance from VMware? I know that Wanda has posted several times on that topic. And instead of MSCS have you looked at any of the HA features/products from VMware? Bill -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Schaub, Steve Sent: Thursday, June 24, 2010 7:51 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Large fileserver on VMware design questions I agree with Remco regarding the use of MSCS clusters in a VMWare environment. We currently have an MSCS fileserver cluster on physical machines, but we are debating moving to multiple, smaller vm's (or a single filer, as per my previous post - although all the drawbacks of NDMP that everyone has pointed out certainly makes me nervous). If we do go vm, we have debated whether the extra hassle of MS clustering buys us anything. Right now, the feeling is that clustering only protects against physical problems, which are obviated by using VMWare. Plus my understanding is that in order to run clustering in a supported configuration, the vm's have to use raw disks, which means VCB backups are out the window. -steve schaub -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: Thursday, June 24, 2010 1:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Large fileserver on VMware design questions On 24 jun 2010, at 02:25, Steve Harris wrote: Hi gang One of my customers is implementing a consolidated fileserver. This will run in a two way MSCS Cluster. At the moment they are looking at one big filesystem though I will strenuously attempt to dissuade them from that course. Each machine in the cluster is a VM based on a different VMware physical server, running windows 2008 r2 64 bit. TSM client will run on the VMs. If they're going to use VMWare, why use a windows cluster. Can't they achieve the same with VMWare? My proposed strategy is: - Daily incremental. With journalling. Standard cluster setup with one scheduler for each machine and one for the cluster resource. Journal database resides on the cluster disk. Makes sense. But, I'm now assuming that the individual machines disks are fairly static, so why bother with the TSM incremental backups, and not live by weekly VCB backups alone for those? If you run in a cluster, there are some tweaks to the journal service to just trust the journal DB, rather than purge it in case of a fail-over. - Weekly VCB image of the cluster disk(s) to enable fast restore after disk failure. can do. - Monthly incremental. Since journalling can't be used on more than one node-name, the monthly incremental will take days and is run by a separate scheduler in the cluster as follows:- -- VSS snapshot of the cluster disk is mounted -- backup is taken -- snapshot is deleted. -- NB VSS snaphots are machine-specific so a failover kills this why? Use journaling for the cluster disks, with a dedicated hostname for the cluster. It might be a good idea to run a normal incremental once in a while, esp. if you don't do a normal incremental after a cluster failover. Questions - Most changing documents are word/excel/powerpoint. Is subfile backup a good fit here on the daily client? What about overhead? subfile incremetals are very useful for clients with 28k8 modem connections. I wouldn't bother in a normal data center environment with plenty of bandwidth. - How does one handle the possibility of failover when taking the VCB image? The volume may be mounted on the other VM - can anybody help with scripts for the monthly VSS snapshot backup? Other than the one large filesystem issue is there any obvious flaw in my strategy? Yes, TSM client 6.2 is not supported with the 5.5 server ;-) TSM Server is 5.5, I will install the 6.2.1 client but this server won't be upgraded for a while. Thanks for your input Steve. Steven Harris TSM Admin Paraparaumu NZ -- Met vriendelijke groeten/Kind regards, Remco Post - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
Re: Large fileserver on VMware design questions
Steven, if you are running in a Windows Server 2003 ( or greater ) functional level Windows Domain you might consider setting up several smaller file servers and implementing DFS Namespaces and DFS Replication too. Ray CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
Re: Large fileserver on VMware design questions
Thanks to Remco, Paul, Daniel, Steve, Bill and Ray for your input. Remco, As a backup service provider I don't get a lot of input into the designs, I'm expected to just take whatever is thrown at me and back it up. This particular customer has got the VMware Religion and is virtualizing everything, seemingly without considering whether the box in question is a good fit for virtualization. I could start to rant at this point but I'll spare myself the embarrassment and you the noise. The contract specifies a monthly backup. Images are ok but for a really large filespace you need a big chunk of disk to do the restore and it takes hours just to get one or two files back. Monthly incrementals are a much better option IMHO, provided that they can be done. I'd expect a 1% daily change rate on this disk, but at 10 Million files that is still 100,000 objects a day. If they are like most word/excel docs, they will be changed a number of times in a short period then get left forever, and the deltas get smaller and smaller. I might try subfile and see how it performs. We can always turn it off later. Daniel, Thanks for the Fastback idea. I'm still awaiting recovery point and recovery time objectives for this cluster, and if they are too stringent will consider Fastback. Will Fastback's VSS usage co-exist with other VSS usage? I'm thinking of my monthly incremental here. There is also the problem of needing more disk for the fastback backing store. Steve, I didn't realize the implication that raw disks can't be imaged by VCB backups. But raw disks can be imaged by the BA client, and use VSS for snapshots, so the failover problem solves itself. Bill If I can get hold of the architect I will ask about VDR and VMware failover and why he made those choices. VDR has size limitations as I understand it, and that may be the issue, plus needing more backing store. I'm also not sure that VMware failover is free, or maybe they are just implementing a tried and proven solution. Ray Along with the VMware religion goes consolidation frenzy :) they already have some sort of distributed file space, and obviously there are problems with that hence the move to one single point-of-failure. Good point though. I'm much obliged to you all -- still need a script to snapshot/mount/backup/unmount/delete-shapshot on Win 2k8 Thanks Steve. Steven Harris TSM Admin Paraparaumu, New Zealand.
Large fileserver on VMware design questions
Hi gang One of my customers is implementing a consolidated fileserver. This will run in a two way MSCS Cluster. At the moment they are looking at one big filesystem though I will strenuously attempt to dissuade them from that course. Each machine in the cluster is a VM based on a different VMware physical server, running windows 2008 r2 64 bit. TSM client will run on the VMs. My proposed strategy is: - Daily incremental. With journalling. Standard cluster setup with one scheduler for each machine and one for the cluster resource. Journal database resides on the cluster disk. - Weekly VCB image of the cluster disk(s) to enable fast restore after disk failure. - Monthly incremental. Since journalling can't be used on more than one node-name, the monthly incremental will take days and is run by a separate scheduler in the cluster as follows:- -- VSS snapshot of the cluster disk is mounted -- backup is taken -- snapshot is deleted. -- NB VSS snaphots are machine-specific so a failover kills this Questions - Most changing documents are word/excel/powerpoint. Is subfile backup a good fit here on the daily client? What about overhead? - How does one handle the possibility of failover when taking the VCB image? The volume may be mounted on the other VM - can anybody help with scripts for the monthly VSS snapshot backup? Other than the one large filesystem issue is there any obvious flaw in my strategy? TSM Server is 5.5, I will install the 6.2.1 client but this server won't be upgraded for a while. Thanks for your input Steve. Steven Harris TSM Admin Paraparaumu NZ
Re: Large fileserver on VMware design questions
On 24 jun 2010, at 02:25, Steve Harris wrote: Hi gang One of my customers is implementing a consolidated fileserver. This will run in a two way MSCS Cluster. At the moment they are looking at one big filesystem though I will strenuously attempt to dissuade them from that course. Each machine in the cluster is a VM based on a different VMware physical server, running windows 2008 r2 64 bit. TSM client will run on the VMs. If they're going to use VMWare, why use a windows cluster. Can't they achieve the same with VMWare? My proposed strategy is: - Daily incremental. With journalling. Standard cluster setup with one scheduler for each machine and one for the cluster resource. Journal database resides on the cluster disk. Makes sense. But, I'm now assuming that the individual machines disks are fairly static, so why bother with the TSM incremental backups, and not live by weekly VCB backups alone for those? If you run in a cluster, there are some tweaks to the journal service to just trust the journal DB, rather than purge it in case of a fail-over. - Weekly VCB image of the cluster disk(s) to enable fast restore after disk failure. can do. - Monthly incremental. Since journalling can't be used on more than one node-name, the monthly incremental will take days and is run by a separate scheduler in the cluster as follows:- -- VSS snapshot of the cluster disk is mounted -- backup is taken -- snapshot is deleted. -- NB VSS snaphots are machine-specific so a failover kills this why? Use journaling for the cluster disks, with a dedicated hostname for the cluster. It might be a good idea to run a normal incremental once in a while, esp. if you don't do a normal incremental after a cluster failover. Questions - Most changing documents are word/excel/powerpoint. Is subfile backup a good fit here on the daily client? What about overhead? subfile incremetals are very useful for clients with 28k8 modem connections. I wouldn't bother in a normal data center environment with plenty of bandwidth. - How does one handle the possibility of failover when taking the VCB image? The volume may be mounted on the other VM - can anybody help with scripts for the monthly VSS snapshot backup? Other than the one large filesystem issue is there any obvious flaw in my strategy? Yes, TSM client 6.2 is not supported with the 5.5 server ;-) TSM Server is 5.5, I will install the 6.2.1 client but this server won't be upgraded for a while. Thanks for your input Steve. Steven Harris TSM Admin Paraparaumu NZ -- Met vriendelijke groeten/Kind regards, Remco Post
