Network restructuring advice
-
I adopted a real low availability network. I have 3 physical "servers" (actually desktops): one mail, one a CentOS proxy/dns/dhcp server, and the other an application host hosting a 4 application VMs one application being a document management system with shares a Drobo also being used as a file share to some extent..
A Dell R730 was recently purchased (before I came in) with 3x 480GB SSD. The current systems as a result are suffering performance issues, and despite their crappy old hardware, the company can't tolerate much down time. The business lacks centralized management of ICT systems. I seeking some recommendations on the best way to increase performance, reliability and simplify management. Thanks.
-
What Drobo model is this? The B800fs and the 5N are their NAS devices, AFAIK.
-
The first step, outside of the technical, would be to begin building a business case around the needs to understand the risk aversion financially. Once you have that you at least have solid numbers to talk to the business about rather than feelings.
This can be difficult but try to get a number on downtime. How much money is lost per minute, per hour, per day... something to that effect. This may not be a consistent number, the first five minutes of downtime might be worth zero but the first full day quite a lot. It varies by company. And you must take into account mitigation - like outages at night, time to send people to lunch, working from paper, etc.
Getting this gives us a real means of understanding the needs for availability.
-
Even if you can't leverage all of that information now, you need it for all discussions around availability. They don't make any sense without those numbers as even the smallest investment should be justified against them.
-
What is the total memory footprint of the existing "servers" and what is the full storage capacity of the existing machines and the Drobo?
-
R730xd: 24x2.5" or 12x3.5"?
-
What is the current backup mechanism?
-
@scottalanmiller said:
R730xd: 24x2.5" or 12x3.5"?
I spec sheet stated R730xd motherboard, but it looks like it's a R730 It only came with 8 hot swappable bays.
Looks like this http://cdn0.mos.techradar.futurecdn.net/art/TRBC/Servers/Dell/Dell PowerEdge R730/PE R730 disk detail-420-90.jpg -
The R730 models should all be the same mobo. It's the drive options that determine which one is which. I was wondering if that wasn't actually a standard R730 node. Still a nice bit of kit.
-
@scottalanmiller said:
What is the current backup mechanism?
Prayer. There is an old tape drive that was connected to one of the server (an HP proliant) via but they said there was an issue with it, so none
-
Wow, running off of desktops with no backups and they feel that they can't go down do to the criticality of the systems?
-
Probably want to be thinking about backups before thinking about anything else.
-
@scottalanmiller said:
What is the total memory footprint of the existing "servers" and what is the full storage capacity of the existing machines and the Drobo?
The Drobo is a B800i with 12TB (10.91TB actual) 5.42TB usable, the other for "protection"
Memory is 16GB in the prolian, 2GB in the proxy and about 4GB in the email server.
Current application server stated 678.5GB storage capacity. Can't state the others atm, but given the age and that the are desktops I wouldn't but any bast 500GB -
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.
-
This post is deleted! -
This post is deleted! -
@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.
-
@scottalanmiller said:
The first step, outside of the technical, would be to begin building a business case around the needs to understand the risk aversion financially. Once you have that you at least have solid numbers to talk to the business about rather than feelings.
This can be difficult but try to get a number on downtime. How much money is lost per minute, per hour, per day... something to that effect. This may not be a consistent number, the first five minutes of downtime might be worth zero but the first full day quite a lot. It varies by company. And you must take into account mitigation - like outages at night, time to send people to lunch, working from paper, etc.
Getting this gives us a real means of understanding the needs for availability.
I'm still trying to accumulate this info as I explained to them that they would be able to afford some downtime, and the cost for HA need to be justified against their lost, however they are more concerned with having the system up and working whenever needed, which so far appears to be all day, every day, at any time.
-
@whizzard are you a consultant on this project or in house?
Expectations need to be discovered and defined before you can propose any sort of solution for them.
-
@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.
