Google Cloud Z4M GA: 168.000 GiB Local SSD ve 400 Gbps RDMA

Google Cloud Z4M storage-optimized machine series, Compute Engine’de VM ve bare metal seçenekleriyle genel kullanıma açıldı. Beşinci nesil Intel Xeon Scalable işlemcili instance’larda 168.000 GiB’a kadar Local SSD ve 400 Gbps Cloud RDMA ağı bulunuyor. Seri, checkpointing, dağıtık KV cache ve parallel file system iş yüklerini hedefliyor.

Kısaca RDMA nedir

RDMA (Remote Direct Memory Access), bir makinenin başka bir makinenin belleğine işletim sistemi ve CPU’yu araya sokmadan doğrudan veri yazıp okumasını sağlayan ağ teknolojisidir. TCP’ye göre daha düşük gecikme ve daha az CPU kullanımı hedefler. HPC, dağıtık storage ve GPU cluster’larında yaygındır. InfiniBand ve RoCE en bilinen uygulamalarıdır.

Google Cloud Z4M neyi hedefliyor

Z4M, GPU ve TPU cluster’larının yanında çalışan storage katmanı için tasarlandı. Checkpoint yazımı, dağıtık KV cache veya parallel file system işletiyorsanız darboğaz çoğu zaman disk kapasitesinde olmaz. Asıl darboğaz, verinin diskten GPU’ya giden yolu. Google Cloud Z4M bu iki ucu birlikte büyütüyor: instance başına 168.000 GiB’a kadar Local SSD ve 400 Gbps Cloud RDMA.

Google, Z4M’yi Z3 ile şöyle kıyaslıyor.

• Random read IOPS’te yüzde 70’e kadar artış, tavan 15,6 milyon IOPS
• Sequential read throughput’ta yüzde 110’a kadar artış, tavan 75.600 MiB/s
• VCPU başına 875 GiB Local SSD, en fazla 192 vCPU ve 1.536 GiB bellek

Partnerlerin rakamları kendi testlerinden geliyor. Silk, TCP’ye göre 3,7 kata kadar düşük gecikme bildiriyor, WEKA ise Z3’e göre yaklaşık iki kat read throughput. Shape seçmeden önce kendi iş yükünüzle ölçüm yapın.

42.000 GiB sınırı bakım planını belirliyor

Shape seçimini en çok etkileyecek bilgi bakım davranışı. 42.000 GiB veya daha az Local SSD’li Z4M VM’ler planlı bakımda live migration ile taşınıyor. 84.000 GiB ve üstü VM’ler ile tüm bare metal instance’lar ise kapatılıp yeniden başlatılıyor. Google bu sırada verinin korunduğunu söylüyor, fakat node yeniden başlayana kadar erişilemez durumda kalıyor.

Bu fark doğrudan mimariye yansıyor. Büyük shape’te kesinti kaçınılmaz olduğu için replikasyonu uygulama katmanında kurmanız gerekiyor. Parallel file system veya dağıtık veritabanında aynı verinin kopyaları aynı anda bakıma girmemeli.

Google bakımı birkaç gün önceden bildiriyor. Cluster Director ile instance’ları availability domain’lere yayabilir, bakımı domain’ler arasında kaydırabilirsiniz. Performans öncelikliyse compact topology seçin. Sürekli erişim öncelikliyse spread topology seçin. İkisi aynı anda gelmiyor, seçimi iş yükü belirliyor.

GKE node pool olarak Z4M

Z4M’i GKE’de yeni node pool oluştururken Storage-Optimized ailesinden seçebiliyorsunuz. Local SSD üzerinde stateful iş yükü çalıştırıyorsanız, bakımda yeniden başlayan node Kubernetes için sıradan bir node kesintisi olur. Replica’ların farklı node’lara ve mümkünse farklı availability domain’lere dağıldığını doğrulayın. 84.000 GiB üstü shape’lerde bu dağılım, bakım penceresinin servis kesintisine dönüşüp dönüşmeyeceğini belirliyor.

Z4M şimdilik yalnızca seçili bölgelerde açık. Projenizin erişebildiği zone’larda tipin listelenip listelenmediğine bakın:

gcloud compute machine-types list --filter="name~z4m"

Liste boş geliyorsa bölge açılışı için Google satış temsilcisiyle konuşmanız gerekiyor. Z3’ten geçişin maliyetini bölge fiyat listesinden ayrıca hesaplayın.

RDMA kazanımı yazılıma bağlı

Google, Cloud RDMA ile TCP’ye göre yüzde 60’a kadar düşük veri erişim gecikmesi açıklıyor. Bu kazanımı görmek için storage yazılımınızın RDMA konuşması gerekiyor. Duyuruda adı geçen yollar NVIDIA GPUDirect Storage ve TPUDirect Storage. Google, parallel file system için Weka, Sycomp, Silk ve VDURA’yı örnek gösteriyor. Kendi yazdığınız bir checkpoint servisi TCP üzerinden çalışıyorsa, Z4M’den yalnızca disk tarafının artışını alırsınız.

Local SSD ile ağ throughput’u arasındaki 1,4:1 oranı da dikkate değer. Bu oran, node veriyi yerelde işlerken client’lara line rate’te gönderebilsin diye seçilmiş. Disk ağdan çok daha hızlı olsaydı fazla IOPS boşa giderdi.

Kalıcı veri için Hyperdisk

Z4M, Hyperdisk Balanced, Hyperdisk Throughput ve Hyperdisk Extreme’i destekliyor. Instance başına kapasite 512 TiB’a kadar çıkıyor. Hyperdisk Extreme bir Z4M instance’ında 500K IOPS ve 12.500 MiB/s’ye ulaşıyor, Balanced ise 320K IOPS’te kalıyor.

Kaybedilmemesi gereken veriyi, örneğin veritabanı log’larını ve son geçerli checkpoint’i, Hyperdisk’e yazın. Yeniden üretilebilen veriyi ve sıcak cache’i Local SSD’de tutun. Bu ayrım sayesinde büyük shape’lerdeki yeniden başlatma, veri riskine dönüşmeden yalnızca bir performans kesintisi olarak kalır.