Azure VM Boyutları ve Seçim Rehberi

Tarafındankomut
0 Comments

Azure’da ilk VM’ini ayağa kaldırdığında karşılaştığın o ekran seni tanıdık geliyordur: onlarca boyut seçeneği, birbirinden farklı harf ve rakam kombinasyonları, hangi serinin ne işe yaradığı hakkında hiçbir fikrin yok. Standard_D4s_v5 mi alsam, Standard_E8s_v4 mü? B-serisi neden bu kadar ucuz? Bu yazıda Azure VM boyutlandırmasının gizemini çözeceğiz ve gerçek dünya senaryoları üzerinden doğru seçimi nasıl yapacağını anlatacağım.

Azure VM Boyut İsimlendirme Mantığı

Azure’da VM boyutları rastgele isimlendirilmiyor. Bir kez bu sistemi kavradığında, ismin kendisi sana o VM hakkında çok şey anlatıyor.

Genel format şu şekilde: Standard_[Aile][Alt Aile][vCPU Sayısı][Kısıtlamalar][Versiyon]

Örneğin Standard_D4s_v5 için:

  • Standard: Fiyatlandırma katmanı (Basic artık kullanımda değil)
  • D: Genel amaçlı aile
  • 4: 4 vCPU
  • s: Premium SSD desteği var
  • v5: 5. nesil donanım

Ek harflerin anlamlarına bakalım:

  • s: Premium SSD desteği
  • d: Lokal geçici NVMe/SSD disk var
  • l: Düşük bellek (lower memory)
  • m: Çok fazla bellek (massive memory)
  • r: RDMA desteği
  • i: Isolated, tek kiracı donanım
  • b: Block storage optimized
  • p: ARM tabanlı işlemci (Ampere)
  • a: AMD işlemci
  • g: GPU var veya donanım hızlandırma

VM Aileleri ve Ne İşe Yararlar

B Serisi: Burstable, Yani Patlamalı

B serisi, arka planda kredi biriktiren ve ihtiyaç duyduğunda bunu harcayan sanal makineler. Sürekli yüksek CPU kullanmıyorsun ama ara sıra patlama ihtiyacın var. Geliştirme ortamları, küçük web sunucuları, test sistemleri için biçilmiş kaftan.

# B serisi VM oluşturma örneği
az vm create 
  --resource-group rg-dev-environment 
  --name vm-dev-app01 
  --image Ubuntu2204 
  --size Standard_B2s 
  --admin-username azureadmin 
  --generate-ssh-keys 
  --output json

Dikkat: B serisi ile prod ortamı kuruyorsan bu bir hata. Kredi tükenince CPU performansı yere çakılır ve oraya gelen kullanıcılar neden site yavaş diye seni arar.

D Serisi: Genel Amaçlı

En çok kullandığım seri bu. Balanced CPU/RAM oranı, çoğu iş yükü için makul fiyat. Web sunucuları, uygulama sunucuları, orta ölçekli veritabanları için ilk bakılacak yer.

# Mevcut VM'in boyutunu kontrol et
az vm show 
  --resource-group rg-production 
  --name vm-webserver01 
  --query hardwareProfile.vmSize 
  --output tsv

D serisi içinde önemli bir fark var: Dv5 vs Dsv5. “s” harfi olmayan versiyonlar Premium SSD desteklemiyor. Eğer disk I/O önemliyse mutlaka “s” versiyonu seç.

E Serisi: Memory Optimized

RAM’e ihtiyacın fazla, CPU o kadar kritik değil. SAP uygulamaları, büyük Redis cache’leri, in-memory veritabanları. E serisi CPU başına D serisinden daha fazla RAM sunuyor.

# E serisi ile SQL Server VM oluşturma
az vm create 
  --resource-group rg-database 
  --name vm-sql-primary 
  --image Win2022Datacenter 
  --size Standard_E8s_v5 
  --admin-username sqladmin 
  --admin-password 'YourSecureP@ssw0rd!' 
  --data-disk-sizes-gb 512 
  --storage-sku Premium_LRS 
  --output json

F Serisi: Compute Optimized

CPU gücü lazım ama RAM o kadar önemli değil. Oyun sunucuları, batch processing, video encoding işlemleri. F serisi CPU’ya odaklanıyor.

L Serisi: Storage Optimized

Lokal NVMe disklerle geliyorlar ve disk I/O kapasitesi inanılmaz. Büyük NoSQL veritabanları, Elasticsearch cluster’ları, yoğun okuma-yazma gerektiren sistemler için.

N Serisi: GPU’lu Makineler

  • NC serisi: CUDA iş yükleri, makine öğrenmesi eğitimi
  • ND serisi: Deep learning, A100 GPU’lar
  • NV serisi: Görselleştirme iş yükleri, sanal masaüstü

M Serisi: Dev Dev Memory

Gigabayt’larla değil terabayt’larla ölçülen RAM. SAP HANA gibi in-memory devler için. Fiyatı da o oranda.

Gerçek Dünya Senaryoları

Senaryo 1: E-ticaret Web Uygulaması

Bir e-ticaret müşterim vardı, Black Friday öncesi panikle aradı. Sitesi yavaşlıyordu. Mevcut durumu:

  • 2x Standard_B4ms web sunucusu (production’da B serisi, ilk hata)
  • 1x Standard_D4s_v3 veritabanı

B serisi kredi tüketmiş, site yavaş. Çözüm olarak boyutları değiştirdik:

# Önce VM'i durdur
az vm deallocate 
  --resource-group rg-ecommerce 
  --name vm-web01

# Boyutu değiştir
az vm resize 
  --resource-group rg-ecommerce 
  --name vm-web01 
  --size Standard_D4s_v5

# VM'i yeniden başlat
az vm start 
  --resource-group rg-ecommerce 
  --name vm-web01

Aynı anda tüm web sunucularını kapatmamak için bu işlemi sırayla yaptık. Load balancer arkasında oldukları için bir sunucu ayakta kalırken diğerini resize ettik.

Senaryo 2: Büyük Log Analizi

Bir müşteri her gece 500 GB log dosyasını işlemek istiyordu. Sürekli çalışan bir VM yerine iş bitince kapanacak bir yapı kuruldu:

#!/bin/bash
# log-processor.sh - Gece 2'de çalışacak script

RESOURCE_GROUP="rg-analytics"
VM_NAME="vm-log-processor"
VM_SIZE="Standard_F32s_v2"

# VM oluştur (spot instance ile maliyet düşür)
az vm create 
  --resource-group $RESOURCE_GROUP 
  --name $VM_NAME 
  --image Ubuntu2204 
  --size $VM_SIZE 
  --priority Spot 
  --eviction-policy Deallocate 
  --max-price 0.5 
  --admin-username logadmin 
  --generate-ssh-keys 
  --custom-data ./log-processor-init.sh

# İşlem bitince VM'i sil
az vm delete 
  --resource-group $RESOURCE_GROUP 
  --name $VM_NAME 
  --yes 
  --no-wait

F serisi seçtik çünkü bu iş tamamen CPU bound. RAM ihtiyacı düşük, hesaplama kapasitesi kritik.

Senaryo 3: SAP Ortamı

SAP BASIS yöneticisiyle çalışırken karşılaştığım tablo buydu:

# SAP HANA için M serisi VM oluşturma
az vm create 
  --resource-group rg-sap-production 
  --name vm-hana-primary 
  --image SLES-SAP 
  --size Standard_M128ms 
  --admin-username sapadmin 
  --generate-ssh-keys 
  --zone 1 
  --storage-sku Premium_LRS 
  --os-disk-size-gb 256

# Ultra Disk ekle (HANA log için gerekli IOPS)
az vm disk attach 
  --resource-group rg-sap-production 
  --vm-name vm-hana-primary 
  --name disk-hana-log 
  --new 
  --size-gb 512 
  --sku UltraSSD_LRS

M128ms: 128 vCPU, 3.8 TB RAM. Bu seviyede VM çalıştırıyorsanız aylık maliyeti de o seviyede. Reserved Instance almadan M serisi çalıştırıyorsanız sizi kimin finanse ettiğini merak ediyorum.

Doğru VM Boyutu Seçmek İçin Metodoloji

Adım 1: İş Yükünü Anla

Başlamadan önce kendine şu soruları sor:

  • CPU mu yoğun, RAM mi yoğun, I/O mu yoğun?
  • Yük sabit mi, yoksa patlamalı mı?
  • Disk erişim paterni nedir? Okuma ağırlıklı mı, yazma ağırlıklı mı?
  • Network bant genişliği kritik mi?
  • Yüksek erişilebilirlik gereksinimi var mı?

Adım 2: Mevcut Sistemi Ölç

Eğer migration yapıyorsan önce mevcut sistemi gözlemle:

# Linux'ta kaynak kullanımını izle
# vmstat ile CPU ve memory durumu
vmstat -w 2 10

# iostat ile disk I/O
iostat -xz 2 5

# sar ile kapsamlı analiz (sysstat paketi gerekli)
sar -u -r -d 1 10

# Anlık kaynak özeti
top -bn1 | head -20
# Windows'ta PowerShell ile kaynak kullanımı
Get-Counter -Counter "Processor(_Total)% Processor Time", `
            "MemoryAvailable MBytes", `
            "PhysicalDisk(_Total)Disk Bytes/sec" `
            -SampleInterval 5 -MaxSamples 12 |
    Select-Object -ExpandProperty CounterSamples |
    Format-Table Path, CookedValue -AutoSize

Bu verileri en az 2 hafta, tercihen 1 ay boyunca topla. Peak dönemleri mutlaka yakala.

Adım 3: Sağ Taraflı Başla, Sol Tarafa Büyü

Küçük başla, gerek olunca büyüt. Azure’da resize kolay ama şunu bilmek gerekir: bazı boyuttan başka boyuta geçiş için VM’in başka bir host’a taşınması gerekiyor ve bu kısa bir downtime yaratır.

# Belirli bir boyuttan geçilebilecek boyutları listele
az vm list-vm-resize-options 
  --resource-group rg-production 
  --name vm-webserver01 
  --query "[].name" 
  --output table

Adım 4: Azure Monitor ile İzle

VM’i ayağa kaldırdıktan sonra Azure Monitor üzerinden izlemeyi mutlaka kur:

# Azure Monitor ile alert oluştur - CPU %80'i geçerse bildir
az monitor metrics alert create 
  --name "High-CPU-Alert-WebServer" 
  --resource-group rg-production 
  --scopes "/subscriptions/{sub-id}/resourceGroups/rg-production/providers/Microsoft.Compute/virtualMachines/vm-webserver01" 
  --condition "avg Percentage CPU > 80" 
  --window-size 5m 
  --evaluation-frequency 1m 
  --action-group "/subscriptions/{sub-id}/resourceGroups/rg-production/providers/microsoft.insights/actionGroups/ag-ops-team" 
  --description "CPU kullanimi kritik seviyeye ulasti"

Maliyet Optimizasyonu Stratejileri

Reserved Instances

Eğer VM’in 1 yıl veya daha uzun süre çalışacaksa Reserved Instance al. Tasarruf genellikle yüzde 30-60 arasında.

# Mevcut VM'lerin kullanım durumunu kontrol et
az consumption usage list 
  --start-date 2024-01-01 
  --end-date 2024-01-31 
  --query "[?contains(instanceName, 'vm-')].{VM:instanceName, Cost:pretaxCost}" 
  --output table

Spot Instances

Test, geliştirme ve toleranslı iş yükleri için Spot kullan. Yüzde 60-90 arası tasarruf mümkün ama VM Azure tarafından herhangi bir anda kapatılabilir.

Dev/Test Ortamları İçin Otomatik Kapatma

Gece 19:00’dan sabah 08:00’a kadar dev ortamlarını kapat:

# VM için otomatik kapatma ayarla
az vm auto-shutdown 
  --resource-group rg-development 
  --name vm-dev01 
  --time 1900 
  --timezone "Turkey Standard Time" 
  --email "[email protected]"

Bu basit ayar, dev ortamlarında aylık maliyeti neredeyse yarı yarıya düşürür. Unutulan VM’lerin sizi ne kadar yakabildiğini bir düşünün.

Azure Hybrid Benefit

Zaten Windows Server veya SQL Server lisansın varsa Azure Hybrid Benefit ile lisans maliyetini ödemezsin:

# Mevcut VM'e Hybrid Benefit uygula
az vm update 
  --resource-group rg-production 
  --name vm-windowsapp01 
  --license-type Windows_Server

Sık Yapılan Hatalar

Herkese aynı boyutu vermek: Sysadminlerin klasik hatası. “Hepsine D4s_v5 verelim biter” mantığı. Veritabanı sunucusu ayrı boyut, web sunucusu ayrı boyut ister.

Over-provisioning: “Yetmez diye korktum” diyerek gereğinden büyük VM almak. Azure’da kaynak israfını izlemek için Azure Advisor kullanın, düşük kullanımlı VM’leri size gösteriyor.

B serisi ile production kurmak: B serisi kredi sistemiyle çalışıyor. Sürekli yüksek yük altında kalan B serisi VM, baseline CPU’ya düşer ve ciddi performans sorunları yaratır.

Disk ve ağ limitlerini görmezden gelmek: Her VM boyutunun maksimum IOPS limiti ve ağ bant genişliği var. Küçük bir VM’e çok büyük diskler ekleyip IOPS’un artacağını sanmak yanlış. VM boyutu IOPS’u da kısıtlıyor.

Availability Zone’u atlamak: Production VM’lerini mutlaka Availability Zone ile konuşlandır. Tek zone’da kalan bir prod ortamı, o zone’un sorun yaşamasıyla birlikte çöker.

Hangi Boyutu Seçeceğimi Hızlıca Nasıl Bilirim?

Basit bir karar ağacı:

  • Test/Geliştirme ortamı ise B serisi
  • Genel web/uygulama sunucusu ise D serisi
  • RAM yoğun iş yükü (cache, in-memory DB) ise E serisi
  • CPU yoğun iş yükü (encoding, hesaplama) ise F serisi
  • Yoğun I/O gerektiren iş yükü (NoSQL, Elasticsearch) ise L serisi
  • SAP HANA veya kritik in-memory sistemler ise M serisi
  • GPU gerektiren iş yükü (ML, görselleştirme) ise N serisi
# Azure'da belirli bir bölgede mevcut VM boyutlarını listele
az vm list-sizes 
  --location westeurope 
  --query "[?numberOfCores >= 4 && memoryInMb >= 8192].{Name:name, CPU:numberOfCores, RAM_GB:memoryInMb}" 
  --output table
# Belirli bir tag ile işaretli VM'lerin boyutlarını raporla
az vm list 
  --query "[?tags.Environment=='Production'].{Name:name, Size:hardwareProfile.vmSize, RG:resourceGroup}" 
  --output table

Bu iki komut günlük operasyonlarda çok işine yarayacak. Özellikle hangi prod VM’lerin hangi boyutta çalıştığını hızlıca görmek için ikincisi favorim.

Sonuç

Azure VM boyutu seçimi bir bilim değil ama sistematik bir yaklaşım gerektiriyor. Önce iş yükünü anla, ölç, sonra karar ver. B serisini production’dan uzak tut. Reserved Instance’ları görmezden gelme, ciddi para tasarrufu sağlar. Dev ortamlarına otomatik kapatma koy, her ay sonu faturada sürprizle karşılaşma.

En iyi VM boyutu, günümüzde “yeterli” olan boyuttur. Bugün küçük başla, Azure Monitor’un sana söylediklerine kulak ver, gerektiğinde büyüt. Over-provisioning ile under-provisioning arasındaki o tatlı noktayı bulmak, iyi bir sysadmini kötüsünden ayıran şeylerden biri. Sorularını yorumlara bırak, deneyimlerini paylaş.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir