Cannot decide between 1U servers for growing company
-
@ntoxicator said:
So if anyone can explain to me
To do away with centralized storage such as what we have now and I've been moving to. I suppose this is what I've grown use to.
In order to have localized storage at the node/hypervisor level. one or many of the hypervisors would be storing all the data and sharing out the NFS? Then its replicated between? probably with DRBD Storage.
however, would would this be done with Citrix Xen Server for instance?
there are a couple of methods used there in the hyperconverged space. Two different schools of thought emerged on how best to simplify the architecture while maintaining the benefits of virtualization.
-
Simply virtualize the SAN and it's controllers - also known as pulling the SAN into the servers. The VSA or Virtual San Appliance approach was developed to move the SAN up into the host servers through the use of a virtual machine. This did in fact simplify things like implementation and management by eliminating the separate SAN. However, it didn't do much to simplify the data path or regain efficiency. The VSA consumed significant host resources (CPU and RAM), still used storage protocols, and complicated the path to disk by turning the IO path from application->RAM->Disk into application->RAM->hypervisor->RAM->SAN controller VM->RAM->hypervisor->RAM->write-cache SSD->Disk.
-
Eliminate the dedicated servers, storage protocol overhead, resources consumed and associated gear by moving the hypervisor directly into the OS of the storage platform as a set of kernel modules, thereby simplifying the architecture dramatically while regaining the efficiency originally promised by Virtualization.
-
-
@ntoxicator said:
So if anyone can explain to me
To do away with centralized storage such as what we have now and I've been moving to. I suppose this is what I've grown use to.
In order to have localized storage at the node/hypervisor level. one or many of the hypervisors would be storing all the data and sharing out the NFS? Then its replicated between? probably with DRBD Storage.
however, would would this be done with Citrix Xen Server for instance?
You could also look at Starwinds Virtual SAN. Which could do this as well.
-
@scottalanmiller said:
It is that it is on a LUN now that is limiting you. If it was on a NAS instead of a SAN, you'd have more options.
Scott, where's your link explaining the difference?
-
@Dashrender said:
@scottalanmiller said:
It is that it is on a LUN now that is limiting you. If it was on a NAS instead of a SAN, you'd have more options.
Scott, where's your link explaining the difference?
One is block the other is file?
-
@coliver said:
@Dashrender said:
@scottalanmiller said:
It is that it is on a LUN now that is limiting you. If it was on a NAS instead of a SAN, you'd have more options.
Scott, where's your link explaining the difference?
One is block the other is file?
The purpose of my post was to show that the OP was using his NAS as both NAS and SAN simultaneously to ensure Scott's point wasn't being lost when he was indicating the use of a SAN or NAS.
-
@ntoxicator said:
So if anyone can explain to me
To do away with centralized storage such as what we have now and I've been moving to. I suppose this is what I've grown use to.
In order to have localized storage at the node/hypervisor level. one or many of the hypervisors would be storing all the data and sharing out the NFS? Then its replicated between? probably with DRBD Storage.
however, would would this be done with Citrix Xen Server for instance?
No NFS, SMB, iSCSI or anything involved with the DRBD scenario. It's raw block storage replication all the way down in the stack. Never need to look at high level stuff. The storage is visible to both nodes at the same time locally. No sharing protocols at all.
With XenServer you could do this yourself but for best results you'd likely use HA-Lizard which is a set of tools around DRBD on XenServer handling all of the complication for you. Not only is it free, but the HA-Lizard team participates here in the community a little.
-
@Dashrender said:
@ntoxicator said:
shit me for getting torn to shreds on here. Pissing contest.
Its much easier to verbalize than type out exact specifics.
What i meant by "I just seen as Windows iSCSI initiator working much better; more manageable and not limited."
Am I currently using windows iSCSI initator? NO
Do I wish I was using it: Yes?Why: Because I feel it would be easier to manage and connect an iSCSI LUN as localized storage and data storage. The larger 2TB storage holds all the windows network shares and user profile data.... thats the problem.
So disconnect the LUN from the XenServer and connect it directly to ProxMox, then give that drive to the windows VM. does that not work in ProxMox?
SANs do not work that way.
-
@coliver said:
@ntoxicator said:
So if anyone can explain to me
To do away with centralized storage such as what we have now and I've been moving to. I suppose this is what I've grown use to.
In order to have localized storage at the node/hypervisor level. one or many of the hypervisors would be storing all the data and sharing out the NFS? Then its replicated between? probably with DRBD Storage.
however, would would this be done with Citrix Xen Server for instance?
You could also look at Starwinds Virtual SAN. Which could do this as well.
But is limited to Hyper-V for best results and can make due in the VMware world but is inferior (but you shouldn't be looking at ESXi anyway so not a big deal.)
-
@scottalanmiller said:
@Dashrender said:
@ntoxicator said:
shit me for getting torn to shreds on here. Pissing contest.
Its much easier to verbalize than type out exact specifics.
What i meant by "I just seen as Windows iSCSI initiator working much better; more manageable and not limited."
Am I currently using windows iSCSI initator? NO
Do I wish I was using it: Yes?Why: Because I feel it would be easier to manage and connect an iSCSI LUN as localized storage and data storage. The larger 2TB storage holds all the windows network shares and user profile data.... thats the problem.
So disconnect the LUN from the XenServer and connect it directly to ProxMox, then give that drive to the windows VM. does that not work in ProxMox?
SANs do not work that way.
Do we need another thread for an explanation of why not? I don't understand why not, at least not as stated.
-
@scottalanmiller said:
@coliver said:
@ntoxicator said:
So if anyone can explain to me
To do away with centralized storage such as what we have now and I've been moving to. I suppose this is what I've grown use to.
In order to have localized storage at the node/hypervisor level. one or many of the hypervisors would be storing all the data and sharing out the NFS? Then its replicated between? probably with DRBD Storage.
however, would would this be done with Citrix Xen Server for instance?
You could also look at Starwinds Virtual SAN. Which could do this as well.
But is limited to Hyper-V for best results and can make due in the VMware world but is inferior (but you shouldn't be looking at ESXi anyway so not a big deal.)
Doesn't work well with Xen? I thought they supported it.
-
@Dashrender said:
@scottalanmiller said:
It is that it is on a LUN now that is limiting you. If it was on a NAS instead of a SAN, you'd have more options.
Scott, where's your link explaining the difference?
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@ntoxicator said:
shit me for getting torn to shreds on here. Pissing contest.
Its much easier to verbalize than type out exact specifics.
What i meant by "I just seen as Windows iSCSI initiator working much better; more manageable and not limited."
Am I currently using windows iSCSI initator? NO
Do I wish I was using it: Yes?Why: Because I feel it would be easier to manage and connect an iSCSI LUN as localized storage and data storage. The larger 2TB storage holds all the windows network shares and user profile data.... thats the problem.
So disconnect the LUN from the XenServer and connect it directly to ProxMox, then give that drive to the windows VM. does that not work in ProxMox?
SANs do not work that way.
Do we need another thread for an explanation of why not? I don't understand why not, at least not as stated.
Sure, just ask the question and I'll respond. I'm racing to keep up today between busy site and kids all over the place and my dad visiting
Ask the full question about moving from Xen to KVM because that's where the rub is. -
as I think about it, the LUN disconnect / reconnect might work as it is Linux handling the connection on both ends. Assuming you have Xen with Linux, but that's a safe assumption.
-
We use lots of 1U Servers.
Only servers that are 2U are backup appliances (which have 40TB of storage)
However, that being Said 400 is relatively small and when I worked at companies that small we usually used 2U with local replicated storage.
Also do not used ProxMox.. Just don't it's a toy.
-
@coliver said:
@scottalanmiller said:
@coliver said:
@ntoxicator said:
So if anyone can explain to me
To do away with centralized storage such as what we have now and I've been moving to. I suppose this is what I've grown use to.
In order to have localized storage at the node/hypervisor level. one or many of the hypervisors would be storing all the data and sharing out the NFS? Then its replicated between? probably with DRBD Storage.
however, would would this be done with Citrix Xen Server for instance?
You could also look at Starwinds Virtual SAN. Which could do this as well.
But is limited to Hyper-V for best results and can make due in the VMware world but is inferior (but you shouldn't be looking at ESXi anyway so not a big deal.)
Doesn't work well with Xen? I thought they supported it.
If it can be used with Xen, which I am unaware of being supported or available, it would only be able to do so in the "Vmware" style fallback VM mode which is vastly inferior to DRBD. It's their integration with Hyper-V in the Dom0 that makes them super powerful there. Definitely not happening on Xen today.
-
Ok so I'll scratch the Proxmox ideal. As right, it probably wouldnt scale. meh.
But I do know and have been planning to migrate away from iSCSI over to NFS storage for Xen Server. I already started... but the issue is with migrating the storage from the current local disk to new local disk that gets assigned to the VM
Still 100% confused on local replicated storage.
Scott made a comment on Xen Server with HA-Lizard
But wouldnt all that storage replication STILL be handled over 1Gbe backbone??!
-
@ntoxicator said:
Scott made a comment on Xen Server with HA-Lizard
But wouldnt all that storage replication STILL be handled over 1Gbe backbone??!
Yes, ONLY way to avoid that is to abandon HA and move on. HA requires certain things that you can't get away from even if you improve the architecture.
Our Scale cluster has a dedicated 10GigE SAN network, for example, to overcome that. Huge throughput and sharing nothing with other functions.
-
UPDATE
Oracle just got back to me on Pricing. Made me puke
10K PER server for a F*** simple 1U box? what f[moderated] is going on with this market, have I completely lost touch?
-
@scottalanmiller said:
@ntoxicator said:
Scott made a comment on Xen Server with HA-Lizard
But wouldnt all that storage replication STILL be handled over 1Gbe backbone??!
Yes, ONLY way to avoid that is to abandon HA and move on. HA requires certain things that you can't get away from even if you improve the architecture.
Our Scale cluster has a dedicated 10GigE SAN network, for example, to overcome that. Huge throughput and sharing nothing with other functions.
It doesn't have to. @ntoxicator was talking about installing a 10 GB network for replication.
-
@ntoxicator said:
Still 100% confused on local replicated storage.
Which aspects? Think of it like SAN. If you want HA SAN you need a replicated cluster of SAN. If you do that, the replication handles one point of fragility but you still need to buy multiple SAN devices, have a network to connect them to the compute nodes, etc. If you move from SAN to DAS you can eliminate some of the networking complexity meaning you get even safer and less complicated, but you still have extra devices to fail and more cost.
Take this to the next level, move the DAS from external to internal and have it be part of the compute devices. You lower cost by removing the extra boxes and reduce risk by reducing the number of parts.
Each move towards local increases reliability and lowers latency and increases bandwidth while lowering cost. It's all win.
