3 ms·

It's absolutely an issue in servers. Within the past month, I have worked with two massive global banks that are backpedaling on adoption of NVMe at scale due t

It's absolutely an issue in servers. Within the past month, I have worked with two massive global banks that are backpedaling on adoption of NVMe at scale due to power draw concerns. They ran the numbers, and the performance benefits of NVMe in most use cases don't justify the costs of retrofitting their data centers to handle the increased power draw associated with NVMe (2-3x per disk compared to SAS SSD). Granted, this is a somewhat self inflicted problem: the banks' data centers were built on the assumption that power-hungry storage platforms would always be isolated to a relatively small footprint, but they are adopting hyperconverged storage architecture as their new operating standard for the future. Newer data centers sized for the increased power draw associated with hyperconverged/converged infrastructure don't tend to have this problem.

btown 5y ago
Curious - what's the general rationale for hyperconverged storage at a bank across the entire footprint? I'd imagine that data storage systems would need to have highly restricted APIs and strong persistence requirements, so you'd naturally tier your services as you would between an application/service layer and a database layer, as would be common for web applications. Certainly the database layer would benefit from converged infra, but wouldn't it be overkill to provide that to nodes running application & service code that shouldn't be doing much, if any, persistence to local drives?
- sithadmin 5y ago
  There's a few factors at play. The first is that the % of apps at a global bank that follow a sensible modern design pattern is often surprisingly small; these are gargantuan, risk-averse (and hence change-averse) organizations that are just now barely wrapping their head around the idea of modern application infrastructure for core business needs. So each bank tends to have absolutely, stupidly enormous legacy app footprints. Next, there's the VDI factor - these banks are nearly entirely reliant on VDI for most employees. Most work cannot be done without connecting to a Citrix or Horizon session. As a random I/O-heavy workload, VDI benefits greatly from the hyperconverged infrastructure model in terms of cost efficacy. Also, these banks never pay anywhere close to list price to license any of their software, so the incremental cost of spinning up a cluster to support apps with relatively meagre storage requirements is often close to negligible, which is a strong advantage over the operational costs associated with setting up dedicated storage appliances.
  - btown 5y ago
    Makes a ton of sense, thanks! Though the idea that critical banking information is just chilling on cluster-local drives rather than in replicated and continuously backed-up database systems is... a wee bit unnerving!
    - sithadmin 5y ago
      Nothing unnerving about it; every hyperconverged storage platform out there uses some sort of RAIN type architecture with all data replicated across 2 or more mirrors within a cluster, or spread out in stripes using an erasure coding algorithm with parity bits. Real-time storage-layer replication to another cluster is an optional feature for extremely critical use a cases, but most orgs just rely on their backup and replication measures to handle availability concerns where a cluster ends up completely dead. Cases where hyperconverged storage is used without making allowances for availability are generally limited to purely ephemeral workloads (e.g. 'disposable' virtual desktops that re-compose on logout) or workloads with app-level availability through ring topology, sharding, etc.

btown 5y ago

Curious - what's the general rationale for hyperconverged storage at a bank across the entire footprint? I'd imagine that data storage systems would need to have highly restricted APIs and strong persistence requirements, so you'd naturally tier your services as you would between an application/service layer and a database layer, as would be common for web applications. Certainly the database layer would benefit from converged infra, but wouldn't it be overkill to provide that to nodes running application & service code that shouldn't be doing much, if any, persistence to local drives?

sithadmin 5y ago
There's a few factors at play. The first is that the % of apps at a global bank that follow a sensible modern design pattern is often surprisingly small; these are gargantuan, risk-averse (and hence change-averse) organizations that are just now barely wrapping their head around the idea of modern application infrastructure for core business needs. So each bank tends to have absolutely, stupidly enormous legacy app footprints. Next, there's the VDI factor - these banks are nearly entirely reliant on VDI for most employees. Most work cannot be done without connecting to a Citrix or Horizon session. As a random I/O-heavy workload, VDI benefits greatly from the hyperconverged infrastructure model in terms of cost efficacy. Also, these banks never pay anywhere close to list price to license any of their software, so the incremental cost of spinning up a cluster to support apps with relatively meagre storage requirements is often close to negligible, which is a strong advantage over the operational costs associated with setting up dedicated storage appliances.
- btown 5y ago
  Makes a ton of sense, thanks! Though the idea that critical banking information is just chilling on cluster-local drives rather than in replicated and continuously backed-up database systems is... a wee bit unnerving!
  - sithadmin 5y ago
    Nothing unnerving about it; every hyperconverged storage platform out there uses some sort of RAIN type architecture with all data replicated across 2 or more mirrors within a cluster, or spread out in stripes using an erasure coding algorithm with parity bits. Real-time storage-layer replication to another cluster is an optional feature for extremely critical use a cases, but most orgs just rely on their backup and replication measures to handle availability concerns where a cluster ends up completely dead. Cases where hyperconverged storage is used without making allowances for availability are generally limited to purely ephemeral workloads (e.g. 'disposable' virtual desktops that re-compose on logout) or workloads with app-level availability through ring topology, sharding, etc.