Additionally, are we talking about 100% availability? That, in no circumstances, must the supporting file server ever fail when the primary fails? Or it’s acceptable for there to be some potential outage where both end up offline.
To the original poster: It’s one thing to ask “has anyone tried ‘x’ – what was your experience?” – that implies that you’ve already done some analysis to indicate that ‘x’ is a good fit for your problem. It’s another thing to say “I need a solution to problem ‘y’”, where you haven’t even defined what problem ‘y’ is. Cheers Ken From: [email protected] [mailto:[email protected]] On Behalf Of Stringham, Steven Sent: Friday, 16 January 2015 3:47 AM To: [email protected] Subject: RE: [NTSysADM] Windows File Server High-Availability Yes, access to your files. Is that?: 1) Uninterrupted – end user has no knowledge that there is an outage. All open files are still viable, ongoing read/write is active – no pause in action. 2) Uninterrupted – end user has little knowledge – there is a short pause, (2-90 seconds) and then they can reconnect to the same path. 3) Small interruption - End user can map to the new path and continue immediately. 4) Larger interruption – end user has same path but there was some time (2-30 minutes?) where administrative (automated or not) tasks made it now available? 5) Larger interruption – end user can map to new path but there was some time (2-30 minutes?) where administrative (automated or not) tasks made it now available? Each of these has a different budget requirement. And a potentially different set of solutions. And are the HA in the same datacenter, or HA across different datacenters? Apparently (by the original email) in the same datacenter. I don’t mean to be a jerk here, but these small definitions make a large difference. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kish n Kepi Sent: Thursday, January 15, 2015 9:21 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Windows File Server High-Availability By highly-available, he means that if the current file server tanks for whatever reason, that we will still have access to our files. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ken Schaefer Sent: Thursday, January 15, 2015 2:21 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Windows File Server High-Availability What does “highly available” actually mean – do you have an quantifiable or non-functional statements to describe this? What is your budget? Any other constraints? What are your other requirements (beyond loosely defined “HA”?) Cheers Ken From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kish n Kepi Sent: Thursday, 15 January 2015 4:42 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Windows File Server High-Availability Hello All, My boss requested that I make our File Server highly available. We currently have a physical server running Windows 2012, with shares published using DFS. The server has large quantities of DAS, some of which are shared primarily for IT dept use, and is connected to an 8 TB SAN which has the main, most used, share. I know that I can go out and purchase another physical file server and connect it to the same SAN LUN and finish the requirement. Besides acting as a file server, this server also serves WSUS and WDS. However, I’m thinking that it may make more sense to create 2 VMs on 2 existing separate physical hosts and create a cluster . The question is how I’d attach the SAN LUN to the virtual cluster. Would I need to create a virtual disk on the SAN, attach it to the cluster and copy the contents of the shares into that virtual disk? The downside of a virtual disk is that once created, it’s difficult to resize if necessary, and unwieldy to copy/move to a new SAN that we will certainly need to get eventually. Any input for either scenario welcome, and I certainly will embrance any new ideas of how to accomplish this task. Kish N Kepi ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
