Compute, Network ve Storage Birlikte Nasıl Çalışır?

Ön koşul: bir iş hizmetini uygulama, platform, IT kaynağı ve fiziksel tesis katmanlarına ayırabilmelisin. Bu dersin sonunda CPU, bellek, ağ ve storage kaynaklarının bir iş yükünü nasıl birlikte taşıdığını açıklayabilecek; fiziksel kaynak ile VM/container gibi mantıksal tüketim katmanını ayırabilecek; north–south ve east–west veri akışlarını basit bir diyagramda gösterebilecek; performans iddiasını uçtan uca ölçüm ve darboğaz kanıtıyla sorgulayabileceksin. Sürenin yaklaşık 27 dakikası kavram ve örneklere, 15 dakikası akış haritasına, 10 dakikası kontrollere ayrılır. Bu ders ayrıntılı protokol yapılandırması veya ürün sizing’i öğretmez. Hedef, sonraki teknik uzmanlık modüllerinde hangi metriğin hangi katmana ait olduğunu ve bir değişikliğin diğer kaynak havuzlarında nasıl etki yaratacağını anlayacağın ortak zemini kurmaktır.

İş yükü, çalışan yazılımdan daha geniş bir kavramdır: kullanıcı ve işlem deseni, veri miktarı, eşzamanlılık, büyüme, gecikme hassasiyeti, çalışma saatleri, yoğun dönem, güvenlik ve kurtarma beklentileriyle birlikte ele alınır. Aynı “100 kullanıcı” iki sistemde bambaşka altyapı talebi doğurabilir; biri gün boyu küçük sorgular çalıştırırken diğeri ay sonunda büyük raporlar ve toplu veri aktarımı yapabilir. Compute ihtiyacı çekirdek sayısından önce işlem paralelliği, CPU kullanım deseni, bellek çalışma seti ve hızlandırıcı gereksinimiyle anlaşılır. Network ihtiyacı yalnız port hızından değil akış yönü, paket davranışı, gecikme, kayıp, güvenlik kontrolü ve yedek yolun gerçek kapasitesinden etkilenir. Storage ihtiyacı yalnız terabayt değil erişim modeli, I/O boyutu, okuma-yazma oranı, gecikme, throughput, dayanıklılık ve veri koruma gereksinimi taşır. Pre-Sales iş yükü tanımını metrik sözlüğüne dönüştürmeden ürün kapasitesi konuşmaz.

Sanallaştırma fiziksel CPU, bellek, ağ ve storage kaynaklarını mantıksal havuzlara ayırır. Bir VM’e sekiz vCPU atanması sekiz fiziksel çekirdeğin yalnız o VM’e ayrıldığı anlamına gelmeyebilir; hypervisor birçok VM’in talebini aynı fiziksel kaynak üzerinde zamanlar. Sanal NIC gerçek trafik için sanal switch, host uplink’i, fiziksel switch ve daha üst ağ yollarına bağımlıdır. Sanal disk bir datastore, volume veya başka bir depolama katmanına; o katman da controller, disk/flash ve bağlantı yollarına dayanır. Container farklı bir izolasyon modeli kullanır ve çoğunlukla host işletim sistemi çekirdeğini paylaşır; yine fiziksel kaynak kıtlığı ve ağ/storage bağımlılıkları sürer. Soyutlama operasyonu kolaylaştırır, fiziksel sınırları ortadan kaldırmaz. Pre-Sales mantıksal tahsis ile fiziksel tüketimi aynı tabloda gösterir; oversubscription veya ortak hata alanı kararını “platform halleder” varsayımına bırakmaz.

Veri merkezi ağında north–south trafik veri merkezine giren veya çıkan akışı; east–west trafik içerideki servisler, sunucular ve storage arasında dolaşan akışı anlatır. Modern çok katmanlı uygulamalarda tek kullanıcı isteği iç ağda birçok servis çağrısı üretebilir. Bu yüzden internet bağlantısının boş olması, uygulama ile veri tabanı arasındaki yolun sağlıklı olduğunu kanıtlamaz. Akışı izlerken kaynak ve hedefi, protokol/portu, isim çözümünü, güvenlik ve yük dağıtım noktalarını, fiziksel/sanal switch geçişlerini, yol MTU’sunu, olası asimetriyi ve ölçüm zamanını kaydet. Storage trafiği ayrı fabric kullanabilir veya IP ağıyla paylaşılabilir; her iki durumda da uçtan uca yol ve hata alanı bilinmelidir. Diyagram yalnız kutu ve çizgi değil, trafik yönü, beklenen hacim ve kontrol noktalarını taşımalıdır.

Darboğaz, gözlenen yavaşlığın olduğu yer ile aynı olmak zorunda değildir. Uygulama thread’i storage yanıtını beklerken CPU kullanımı düşük görünebilir; ağ kaybı yeniden iletim üreterek storage gecikmesi gibi hissedilebilir; bellek baskısı işletim sistemini diske yönlendirerek I/O’yu artırabilir. Bu nedenle teşhis sırası hipotez kur, uçtan uca zaman çizgisini ölç, katman metriklerini aynı zaman aralığında ilişkilendir, kontrollü değişiklik yap ve sonucu karşılaştır şeklinde ilerler. Ortalama değerler yoğun anı saklayabilir; tepe, yüzdelik dilim ve kuyruk davranışı iş yükü bağlamında incelenir. Ölçüm aracının kapsamı da yazılır: VM içi CPU metriği hypervisor beklemesini, storage array metriği host veya ağ kuyruğunu, switch portu uygulama işlem süresini tek başına göstermez. Pre-Sales ayrıntılı performans analistinin yerine geçmeden kanıt planını ve sorumlu uzmanları belirler.

Bir kaynağı büyütmek komşu katmanda yeni sınır yaratabilir. Daha hızlı compute daha çok işlem tamamlayıp storage’a daha yoğun I/O gönderebilir. Storage gecikmesini düşürmek uygulama sunucusunda CPU veya lock baskısını görünür kılabilir. VM yoğunluğunu artırmak host sayısını azaltırken daha büyük arıza etkisi, daha yoğun uplink ve bakım sırasında daha az boş kapasite doğurabilir. Veri sıkıştırma kullanılabilir kapasiteyi artırırken CPU tüketimi ve iş yüküne bağlı oran belirsizliği getirir. Bu trade-offlar “iyi/kötü” etiketiyle değil ölçüt ve sınırla yazılır. Tasarım değerlendirmesinde değişecek katman, beklenen olumlu sonuç, etkilenecek komşu kaynaklar, izlenecek metrik, geri dönüş koşulu ve kabul eşiği birlikte kaydedilir. Böylece POC yalnız ürün gösterisi değil, mimari hipotezin sınandığı kontrollü deney olur.

Arven sipariş portalının şikâyeti “öğleden sonra yavaşlıyor.” İlk envanter iki uygulama VM’i, bir veri tabanı kümesi ve paylaşımlı storage gösteriyor. Akış çalışması üç ek gerçeği açıyor: bayi istekleri güvenlik denetiminden sonra İstanbul’a geliyor; uygulama her sepet güncellemesinde kimlik ve stok servisleriyle east–west konuşuyor; aynı host ve uplink grubu öğleden sonra backup proxy trafiğini de taşıyor. Storage ekibi array latency’sinin normal, ağ ekibi ortalama port kullanımının düşük olduğunu söylüyor. Fakat ölçümler farklı beş dakikalık pencerelerden alınmış. Karar vermek için kullanıcı işlem süresiyle aynı zaman damgasında VM bekleme, host uplink, paket kaybı/yeniden iletim, veri tabanı bekleme ve storage latency verisi toplanıyor. Harita, ekiplerin ölçümlerini tek zaman çizelgesinde birleştiren ortak sözlük oluyor.

Toplanan kanıt backup trafiğinin kısa süreli uplink kuyruğu oluşturduğunu ve uygulama–veri tabanı akışının bu pencerede geciktiğini gösterirse karar yalnız “daha hızlı switch” değildir. Seçenekler backup zamanlamasını değiştirmek, trafik sınıflandırması uygulamak, fiziksel yol kapasitesini veya bağımsızlığını artırmak, proxy yerleşimini değiştirmek ve uygulamanın çağrı desenini azaltmak olabilir. Her seçenek performans, operasyon, maliyet ve hata alanı etkisiyle değerlendirilir. Pre-Sales hangi seçeneğin ürün portföyüne yakın olduğundan önce hipotezi, ölçüyü ve yan etkileri yazar. Kanıt hipotezi desteklemiyorsa yön değiştirir; ürün teklifini korumak için ölçümü eğip bükmez.