Network restructuring advice
-
@whizzard said:
@whizzard said:
@hubtechagain said:
Though segmented and long winded... Scott is right.
You need to establish the need for a backup. I'd use the drobo for a backup target. consolidate the other server functions on your actual server hardware using a hypervisor. ESXi, Hyper-V, XenServer etc... whatever flavor you like.
That is what I am considering at the moment, the problem is the current setup already has the data stored on the Drobo, so while it's already there, it isn't a backup as it's where the data actively resides.
The setup is a bit messy, so as much as I want to consolidate what is currently there on proper VMs, some would require reinstallation, which and reconfiguration. I rather do that once and limit the amount of scheduled downtime.
Define downtime here. Each migration piece may or may not incur downtime. But is it better or worse to do one piece at a time or all at once? Could easily go either way. Often a staged approach is the least painful.
-
@hubtechagain said:
not sure why you couldn't P2V. if flat files are being stored on the nas... easy peasy, move to whatever VM it belongs to post p2v. yes, down time will be required. Do it over the weekend, or over night.
P2V should work for the desktops. The Drobo workload we don't know enough about yet. Right now it sounds like a rogue SAN just floating around out there.
-
@hubtechagain said:
Well, if that's their attitude....good luck. Of course we/they/everyone wants it to just work. But if they want it to "always work" that takes a good bit of work/planning/etc IMO easiest of which would be Virtualization either locally with colocation for DR or a pure virtual "cloud" fix. not knowing what the business is, application load etc makes it a little tough to recommend anything specific.
Virtualization goes without saying (we hope.) Colocation is a very important thing to consider, might make a ton of sense. And, of course, moving some workloads to things like Amazon EC2, Azure or Rackspace might make a lot of sense where feasible.
-
@hubtechagain said:
you can.... but you're only as fast as your slowest drive.
When you mix, you are actually just slightly slower than your slowest drive. It's not just a drive performance cap but a per drive, per operation performance cap, so any latency, any bottlenecks anywhere on each individual operation waits for the slowest so even a group of fast drives slows down as they do different operations differently.
-
@Dashrender said:
What is currently running on the R730? Is there enough processing power to run all work loads of the two PCs and whatever is currently on the R730, on the 730?
Sounds like tons more power than needed to handle everything.
-
@Dashrender said:
What are you thinking about for backups? Once you're completely virtualized you could use Veeam, or you could look at getting a Unitrends box (though be prepared for several thousand dollar bill on that one). It doesn't appear that you can use the Drobo as a backup target, as you mentioned it's already being used for live data.
Unitrends does not require an appliance. He could run it as a VM on HyperV or XS and backup to the Drobo.
-
@Dashrender said:
What is currently running on the R730? Is there enough processing power to run all work loads of the two PCs and whatever is currently on the R730, on the 730?
What are you thinking about for backups? Once you're completely virtualized you could use Veeam, or you could look at getting a Unitrends box (though be prepared for several thousand dollar bill on that one). It doesn't appear that you can use the Drobo as a backup target, as you mentioned it's already being used for live data.
You could look into purchasing a used Dell with spinning drives(unless you have budget/performance need for SSDs), virtualize the two PCs onto it.
The 730 is new, the began migrating some of the VMs from the HP Proliant onto it.
I intended to move everything from the Drobo onto the R730 and use the Drobo as backup storage -
@scottalanmiller said:
@whizzard said:
The Drobo is a B800i with 12TB (10.91TB actual) 5.42TB usable, the other for "protection"
All Drobo are limited to RAID 5 or RAID 6, that's all that they do.
The B800i is a rack mounted SAN (I have one myself), it cannot be used as a file share. How exactly is it being used? A SAN is not a file server.
It's connected to the HP Proliant as an additional drive and shared via one of the VMs
-
@whizzard said:
I intended to move everything from the Drobo onto the R730 and use the Drobo as backup storage
How will you be doing this? Are you building a SAN VM on the R730?
-
@whizzard said:
It's connected to the HP Proliant as an additional drive and shared via one of the VMs
Oh that's HORRIBLE. But it means you can drop it completely, it has no function. It's actually doing nothing but adding risk and bottlenecks right now. Just move it into a VHD and you are done.
-
@scottalanmiller said:
@whizzard said:
That is what I am considering at the moment, the problem is the current setup already has the data stored on the Drobo, so while it's already there, it isn't a backup as it's where the data actively resides.
That's going to be very tough. And backing up a SAN is dramatically harder than backing up other storage types as you cannot back it up directly but only through the systems that are attached to it. You can't simply buy another B800i and replicate or get backup software that can back it up. It takes a lot more resources and effort to back up.
The first step, I think, would be prepping the R730 for use for "everything" and migrating that huge B800i workload over to it ASAP. Once that is done, repurpose the B800i as the backup target ASAP.
If the capacity of the B800i is not enough to handle all of the backups once there are versions and whatnot, you can get bigger drives for it to handle that. Or if necessary, a second B800i is not a massive investment.
I like that idea
-
Here us an illustration of what I'm currently working with.
-
You are running email in house? I'd get a meeting together to discuss making that hosted as a first step. That could be something that you don't have to deal with at all.
-
@scottalanmiller said:
You are running email in house? I'd get a meeting together to discuss making that hosted as a first step. That could be something that you don't have to deal with at all.
I mentioned that to them already just to get a feel of where they stand, so far they seem somewhat paranoid about it, but I don't think it's something I can't convince them to move.
-
@whizzard said:
I mentioned that to them already just to get a feel of where they stand, so far they seem somewhat paranoid about it, but I don't think it's something I can't convince them to move.
Like most things, if they feel paranoid it is because they don't understand. All of the things that they told you they want should rule them out running their own email. Security, stability, uptime, protection... those don't go with in house email. Remind them that security and uptime don't mix with hubris or reckless "throwing darts" decision making.
If they want IT to make good decisions, management can't just make uninformed technical decisions. Ask them why they feel that as non-IT they would have any input into whether it is hosted or not? If they are making the call to be insecure and risky, why do they tell you to do the opposite. Make them explain their irrationality.
-
@whizzard said:
....but I don't think it's something I can't convince them to move.
Don't convince them to move, explain to them that they've already mandated to you to do so as part of the requirements already given.
-
I personally use Google Apps, many recommend Office 365, but having seen some global downtime with them, I am a bit apprehensive. Also know Rackspace has some options as well. But so far other than the limited features of the outdated Zimbra, the email hasn't required much yet. So with a backup host in a co-location site and better email server software, will it still be better to move to hosted emails?
-
@whizzard said:
I personally use Google Apps, many recommend Office 365, but having seen some global downtime with them, I am a bit apprehensive.
Define downtime and risk. How much downtime have you seen? How much downtime do you fear? How many incoming emails (down to customers) happened? How much data loss? How much impact was there?
Now look at internal email. Try to assess the same risks there. You can't make internal email as reliable as these services without spending a fortune and even then, it is unlikely. You can get lucky for large periods of time, but overall, the downtime is going to be higher. And different, it requires IT scrambling, no resources to deal with other issues and no infrastructure for failover.
Honestly, a little email downtime is pretty minor when email handling is still working. Security and data protection are the big issues and you can't remotely touch those self hosting.
-
@whizzard said:
So with a backup host in a co-location site and better email server software, will it still be better to move to hosted emails?
Unless you have a regulatory reason or a massive network problem keeping you from going hosted, I know of no reliability, security or data protection reason that would make you run in house under any circumstances. Email is a commodity service that cannot be run in house as effectively as it can be hosted. Using IT resources to run email is no different than using them to run a web server. It's wasteful and inefficient. There is no competitive advantage in running email in house.
-
@scottalanmiller said:
@whizzard said:
So with a backup host in a co-location site and better email server software, will it still be better to move to hosted emails?
Unless you have a regulatory reason or a massive network problem keeping you from going hosted, I know of no reliability, security or data protection reason that would make you run in house under any circumstances. Email is a commodity service that cannot be run in house as effectively as it can be hosted. Using IT resources to run email is no different than using them to run a web server. It's wasteful and inefficient. There is no competitive advantage in running email in house.
Understood