If I need to move a 100TB SAN (block) to GCP what are the options we have? As per my understanding it has to be a persistent disk. But current max limit per disk is 64TB. So I will need two disks. But how multiple machines can share this block storage? It says only one VM can have read/write access and others should be read-only.
Thanks for the feedback. In summary 1. GCP doesn’t have a readymade solution for Block storage greater than 64TB as bulk. 2. 64TB can be W/R for only one VM and other VMs can have only Read Access. 3. If we need BLOCK storage in GCP then we have to build Ceph Storage using Compute Engines as the base line. 4. NFS or Glueter can be used for File Storage requirements.
Please correct me if the above is wrong.
A storage array can obviously present smaller LUNs to multiple hosts, which probably would be different VMs in the cloud. Let's assume that for some reason you need to present the entire thing to one host.
Currently, the documented limits are stronger than 64 TB disks, it is 64 TB total per instance, and less on the smallest instance types.
Most instances can have up to 64 TB of total persistent disk space attached.
Consider a multiple node network file system to access more than that. Either object storage, like their cloud buckets, or a file based protocol like NFS or SMB.
GCP has an overview of some filer products on their platform. These are not the only options, presumably Ceph or GlusterFS could work as well.
You can create two Filestore instances (which are basically NFS servers), and mount them on multiple hosts in read/write mode.
The other option would be to roll your own Gluster/Ceph or similar storage solution.
GCP Offer up to 64TB attached standard persistent disk for each instance.
You can use File Servers on Compute Engine or called a storage filer, this provides a way for you applications to read and update files that are shared across machines. you can share files by using Cloud Storage or Compute Engine persistent disks
Reads and writes are done on the entire file rather than at offsets, which means a full overwrite of the file is necessary when uploading.
When multiple writers are operating at the same time, the last write wins, and overwrites the other changes to the file unless you provide your own synchronization mechanism.
If your application requires access to POSIX file metadata attributes, like last-modified timestamps, you must use the Cloud Storage API rather than a stat call on your host.
Compute Engine persistent disks
With persistent disks, you can attach volumes in both read-write and read-only modes. This means that you can first attach a volume to an instance, load it with the data you need, and then attach it as a read-only disk to hundreds of virtual machines
The most common protocols for exporting file shares are Network File System (NFS) for Linux and the Common Internet File System (CIFS) for Windows.
If latency is not a problem and you're not using a Windows instance, you can also use gcpfuse to map your storage directory to a Cloud Storage bucket. This way you still have block storage and do not have to use multiple persistent disks.
Matthew Ulasien from LinuxAcademy has a great demonstration here.
This basically mounts the Cloud Storage bucket to the directory you specify using a simple command(after setup).
gcsfuse example-bucket /path/to/mount