4 ms·

https://cloud.google.com/compute/docs/disks/#introduction https://cloud.google.com/compute/docs/disks/#introduction Only difference in docs is 1/2 the write th

by nimos 8y ago

https://cloud.google.com/compute/docs/disks/#introduction https://cloud.google.com/compute/docs/disks/#introduction Only difference in docs is 1/2 the write throughput per GB on SSDs. Latency is probably the real issue though. Kind of annoying that neither pricing or performance is even mentioned. Pricing is at a "promo" price of .24 a GB for SSD and .08 for standard.

thesandlord 8y ago
> Latency is probably the real issue though Reads should be just as fast as zonal disks. From the docs: A write is acknowledged back to a VM only when it is durably persisted in both replicas. If one of the replicas is unavailable, Compute Engine only writes to the healthy replica. When the unhealthy replica is back up (as detected by Compute Engine), then it is transparently brought in sync with the healthy replica and the fully synchronous mode of operation resumes. This operation is transparent to a VM. Regional persistent disks are designed for workloads that require a lower Recovery Point Objective (RPO) and Recovery Time Objective (RTO) compared to using persistent disk snapshots. Regional persistent disks are an option when write performance is less critical than data redundancy across multiple zones. (I work for GCP)
- miki4you 8y ago
  am i right to assume that the regional persistent disk can only be mounted in write mode on one node at the time, same as with zonal persistent disk ?
- jorangreef 8y ago
  Do you use vector chains or partially ordered sets etc. to detect or prevent split-brain? e.g. The first replica fails, and the second keeps writing, then the second fails and the first recovers. The second never recovers. Without vector chains, the user would never be made aware that data was lost on the second replica. Or if the second replica recovers, data might be lost when merged.
  - londons_explore 8y ago
    In your example, the disk is entirely read-only I think. I would guess the state of each disk replica (HEALTHY, UNHEALTHY) is stored in a master elected data store. Anytime a write to one replica fails, the data store must be updated to change the state of the failed replica before considering the write complete. Then to change the state back to HEALTHY, everything must be online and fully re-replicated. If the master elected state store can't be written to, because (due to a network split) it doesn't have sufficient votes to gain mastership, then no writes can occur.

by nimos 8y ago

thesandlord 8y ago

> Latency is probably the real issue though Reads should be just as fast as zonal disks. From the docs: A write is acknowledged back to a VM only when it is durably persisted in both replicas. If one of the replicas is unavailable, Compute Engine only writes to the healthy replica. When the unhealthy replica is back up (as detected by Compute Engine), then it is transparently brought in sync with the healthy replica and the fully synchronous mode of operation resumes. This operation is transparent to a VM. Regional persistent disks are designed for workloads that require a lower Recovery Point Objective (RPO) and Recovery Time Objective (RTO) compared to using persistent disk snapshots. Regional persistent disks are an option when write performance is less critical than data redundancy across multiple zones. (I work for GCP)

miki4you 8y ago
am i right to assume that the regional persistent disk can only be mounted in write mode on one node at the time, same as with zonal persistent disk ?
jorangreef 8y ago
Do you use vector chains or partially ordered sets etc. to detect or prevent split-brain? e.g. The first replica fails, and the second keeps writing, then the second fails and the first recovers. The second never recovers. Without vector chains, the user would never be made aware that data was lost on the second replica. Or if the second replica recovers, data might be lost when merged.
- londons_explore 8y ago
  In your example, the disk is entirely read-only I think. I would guess the state of each disk replica (HEALTHY, UNHEALTHY) is stored in a master elected data store. Anytime a write to one replica fails, the data store must be updated to change the state of the failed replica before considering the write complete. Then to change the state back to HEALTHY, everything must be online and fully re-replicated. If the master elected state store can't be written to, because (due to a network split) it doesn't have sufficient votes to gain mastership, then no writes can occur.