4 ms·

This is about a completely different type of VM application, and a completely different kind of storage architecture. This is about everything being on the stor

This is about a completely different type of VM application, and a completely different kind of storage architecture. This is about everything being on the storage box, not just any application state. The two nodes export NFS shares, which host the root filesystems of the nodes being run on the VM servers. Most likely, the two storage heads will be existing on the same subnet as the VMWare boxes, thus making a network partition that affects both nodes much, much less likely. Additionally, by having the sort of architecture being presented, you can do things like live migrations of VMs, which is useful when the underlying OS needs to be brought down for maintenance. There are trade-offs with any architectural decisions, and your idea provides a much more byzantine, complex, and expensive system for little to no trade-off at the scale presented. There are quite a few places where they just need a few servers, and going to your idea just makes things more expensive and more complicated.

insaneirish 10y ago
> This is about a completely different type of VM application, and a completely different kind of storage architecture. I understand it completely, and I vehemently disagree with everything about it. Providing networked block storage for virtual disks on top of NFS is a recipe for disaster and performance degradation. Just because "everyone" does it doesn't make me like it any more. Using redundant local disk (preferably with ZFS) gets around this problem. Blocks are actually blocks and failures and performance issues are confined to one node. > Additionally, by having the sort of architecture being presented, you can do things like live migrations of VMs, which is useful when the underlying OS needs to be brought down for maintenance. I find live migration to be a hack. Once again, solving the wrong problem at the wrong level. > There are quite a few places where they just need a few servers, and going to your idea just makes things more expensive and more complicated. Local disk with appropriate backups and application level failover makes a lot more sense and is fundamentally less complicated.
- user5994461 10y ago
  I really don't understand that fight. SAN storage and VmWare (ESXi) have been around forever. VmWare will gladly provision VMs over any SAN storage. Live migration has been available for more than 10 years (that's called VMotion and it requires any of paid edition). Prefer local storage? Put any sort of local storage on the server, VmWare will gladly provision VM on it. What's the most important thing in a storage... THE BACKUP! For backups, there are snapshots capabilities well integrated into VmWare (cold snapshots, live snapshots, incremental snapsnots, whatever you name it). All of this has existed for more than ten years. Standard protocols (iSCSI, FiberChannel, other) + robust enclosures (all vendors have SAN) + battle tested software and drivers (VmWare). A couple servers and some TB of storage is a nothing fancy. The cost of the setup is shared between the servers + the labor + many SAS hard drives + the enclosure (a very little part). It's really hard to take seriously an overly complex setup that is trying to imitate that over cheap untested hardware and software (NFS? seriously?). Not only it is a recipe for disaster in production but there isn't even any cost savings to be done. The cost of complexity and labors will be going wild with all the configuration. The hardware costs won't go down (still need many drives and servers). Good luck debugging that and retrieving data when things will go wrong. Well. I suppose it's fun for home labs and that's about it :D
  - ewwhite 10y ago
    Huh? I'm not sure I understand.
    - jakezhao100 10y ago
      OK
    - jakezhao100 10y ago
      F

insaneirish 10y ago

> This is about a completely different type of VM application, and a completely different kind of storage architecture. I understand it completely, and I vehemently disagree with everything about it. Providing networked block storage for virtual disks on top of NFS is a recipe for disaster and performance degradation. Just because "everyone" does it doesn't make me like it any more. Using redundant local disk (preferably with ZFS) gets around this problem. Blocks are actually blocks and failures and performance issues are confined to one node. > Additionally, by having the sort of architecture being presented, you can do things like live migrations of VMs, which is useful when the underlying OS needs to be brought down for maintenance. I find live migration to be a hack. Once again, solving the wrong problem at the wrong level. > There are quite a few places where they just need a few servers, and going to your idea just makes things more expensive and more complicated. Local disk with appropriate backups and application level failover makes a lot more sense and is fundamentally less complicated.

user5994461 10y ago
I really don't understand that fight. SAN storage and VmWare (ESXi) have been around forever. VmWare will gladly provision VMs over any SAN storage. Live migration has been available for more than 10 years (that's called VMotion and it requires any of paid edition). Prefer local storage? Put any sort of local storage on the server, VmWare will gladly provision VM on it. What's the most important thing in a storage... THE BACKUP! For backups, there are snapshots capabilities well integrated into VmWare (cold snapshots, live snapshots, incremental snapsnots, whatever you name it). All of this has existed for more than ten years. Standard protocols (iSCSI, FiberChannel, other) + robust enclosures (all vendors have SAN) + battle tested software and drivers (VmWare). A couple servers and some TB of storage is a nothing fancy. The cost of the setup is shared between the servers + the labor + many SAS hard drives + the enclosure (a very little part). It's really hard to take seriously an overly complex setup that is trying to imitate that over cheap untested hardware and software (NFS? seriously?). Not only it is a recipe for disaster in production but there isn't even any cost savings to be done. The cost of complexity and labors will be going wild with all the configuration. The hardware costs won't go down (still need many drives and servers). Good luck debugging that and retrieving data when things will go wrong. Well. I suppose it's fun for home labs and that's about it :D
- ewwhite 10y ago
  Huh? I'm not sure I understand.
  - jakezhao100 10y ago
    OK
  - jakezhao100 10y ago
    F