DEV Community: Hakan İSMAİL

vSAN Stretched Cluster: Site Koruması ve Local Affinity (Modül 4)

Hakan İSMAİL — Sun, 05 Jul 2026 07:51:38 +0000

Üç haftadır SPBM, izleme ve şifreleme konularını işledim. Bu hafta Modül 4'e geçiyorum: vSAN Stretched Cluster. Önceki modüllere göre bu konu kavramsal olarak biraz daha zorlayıcı geldi; tek bir cluster'ı iki fiziksel siteye yaymak, hem ağ mimarisi hem de failure senaryoları açısından yeni bir düşünme biçimi gerektiriyor.

Şunu baştan belirtmek isterim: HOL ortamı bunu tam olarak simüle edemiyor, manuel de bunu açıkça söylüyor. İki site arası gerçek bir 10GbE bağlantısı ya da crossover kablo burada yok. Ama stretched cluster'ı hazırlama adımları ve witness trafiğini ayırma mantığı, gerçek bir direct-connect cluster'da yapılanla aynı.

Stretched Cluster Nedir, Neden Var?

Normal bir vSAN cluster'ı tek bir lokasyonda çalışır. Stretched cluster ise aynı cluster'ı iki fiziksel siteye yayıyor: veri her iki sitede de bir kopya halinde tutuluyor. Amaç, bir sitenin tamamen kaybedilmesi durumunda bile VM'lerin diğer sitede çalışmaya devam etmesi.

Bunu mümkün kılan üçüncü bir bileşen var: Witness Host. Bu, veri taşımayan, sadece quorum (çoğunluk kararı) sağlayan özel bir sanal cihaz. 1+1+1 mimarisi şöyle işliyor: Site 1'de en az bir host, Site 2'de en az bir host, ve ayrı bir yerde bir witness host.

2-Node Direct Connect Senaryosu

vSAN 6.5'ten itibaren 2-node konfigürasyonlarda doğrudan crossover kablo kullanımı destekleniyor. Bu özellikle ROBO (remote office/branch office) senaryolarında değerli: her lokasyona 10GbE switch altyapısı kurmak maliyetli ve karmaşık olabiliyor. İki host'u doğrudan birbirine bağlamak bu maliyeti ortadan kaldırıyor, aynı zamanda karmaşıklığı azaltıp güvenilirliği artırıyor.

Preferred Site Kavramı

Stretched cluster'da "preferred site" (tercih edilen site) diye bir kavram var. Bu, vSAN'a "iletişim koptuğunda hangi tarafın ayakta kalmasını istiyorum" demenin yolu. Denilebilir ki preferred site, en güvenilir olması beklenen taraf.

Mantık şöyle işliyor: Site 1 ile Site 2 arasındaki bağlantı koparsa ama her iki site de witness host'a erişebiliyorsa, preferred site çalışmaya devam ediyor ve bileşenleri aktif kalıyor. Preferred olmayan site'daki storage ise "down" olarak işaretleniyor, bileşenler "absent" durumuna geçiyor.

Bu, klasik bir split-brain önleme mekanizması. Witness, kimin "doğru" taraf olduğuna karar veren hakem rolünü oynuyor.

Read Locality: Okuma Trafiğini Yerel Tutmak

Bu kısım benim için modülün en pratik bilgisi oldu. Normal vSAN'da okuma istekleri, verinin tüm replika kopyaları arasında round-robin şeklinde dağıtılıyor. Stretched cluster'da ise bu davranış değişiyor.

Read locality algoritması, okumaların yüzde yüzünü compute'un bulunduğu site'daki yerel veri kopyasından yapıyor. Mantığı açık: VM'in compute kaynağı Site 1'deyse, okuma isteklerini Site 2'ye göndermek gereksiz bir ağ gecikmesi (latency) yaratır. Bu yeni algoritma, okuma işlemlerindeki gecikmeyi azaltmak için tasarlanmış.

Manuel'de ilginç bir eşik veriyor: Eğer siteler arası gecikme 5ms'nin altındaysa ve yeterli bant genişliği varsa, read locality kapatılabiliyor. Ama bunu kapatmak, okuma trafiğinin yarısının uzak siteye gitmesi anlamına geliyor; bu da ağ bant genişliği planlaması için ciddi bir fark yaratıyor. Manuel ayrıca bunun yalnızca VMware Global Support Services rehberliğinde ve sadece son derece düşük gecikme olan ortamlarda yapılması gerektiğini özellikle vurguluyor. Yani bu varsayılan davranışı kapatmak bir "ileri seviye ayar" değil, neredeyse bir istisna durumu.

Bununla ilgili gizli bir advanced parameter de var: VSAN.DOMOwnerForceWarmCache. Bu, vSphere Web Client'ta görünmüyor, sadece CLI üzerinden erişilebiliyor. Bunun gizli tutulması bana mantıklı geldi; yanlışlıkla değiştirildiğinde etkisi geniş olabilecek bir ayar.

Witness Host: Cluster'ın Dışında Kalan Üye

Burada altı önemle çizilen bir kural var: Stretched cluster yapılandırılırken sadece data host'lar cluster objesinin içinde olmalı. Witness host, cluster dışında kalmalı ve hiçbir aşamada cluster'a eklenmemeli.

HOL ortamında witness host önceden deploy edilmiş durumda: esx-11a.site-a.vcf.lab. Inventory görünümünde bu host'un sunucu ikonunda küçük bir işaret var; bunun normal bir ESX host değil, vSAN 2-Node ve Stretched Cluster mimarilerini desteklemek için kullanılan özel bir sanal cihaz olduğunu gösteriyor.

Witness Networking: İki Ayrı Arayüz

Witness appliance'ın iki ağ adaptörü var, iki ayrı standart switch'e bağlı:

Management VMkernel (vmk0): vCenter ile iletişim için, appliance yönetimi amacıyla.
secondaryPG (vmk1): vSAN ağıyla iletişim için.

Bu ayrım önerilen konfigürasyon. Bu iki arayüz farklı ya da aynı ağlara bağlanabilir, yeter ki ilgili servislere erişimleri olsun. Management arayüzü vSAN trafiğini de taşıyacak şekilde tag'lenebilir, ama bu durumda vmk0'ın hem vCenter'a hem vSAN ağına erişimi olması gerekiyor.

Manuel'de nested ortamlar için ilginç bir not var: VMware'in bu HOL için kullandığı platform gibi birçok nested ESX ortamında, promiscuous mode'u etkinleştirme önerisi var. Sebebi şu: sanal switch, tanımadığı nested vmnic'ler için paketleri düşürebiliyor; promiscuous mode bunu önlüyor. HOL'da bu zaten yapılandırılmış durumda, ama gerçek bir nested ortamda bu ayarı unutursanız witness trafiği sessizce kaybolabilir; bunu hatırlamak gerekiyor.

Witness üzerinde secondaryPg adında önceden tanımlanmış bir portgroup var, vSAN trafiği için kullanılan VMkernel port burada görünüyor. vSAN ağında DHCP sunucusu yoksa (ki genelde yok), VMkernel adaptörünün geçerli bir IP adresi olmayacaktır; bu durumda manuel IP ataması gerekiyor.

Static Route Gerekliliği

Stretched cluster yapılandırılmadan önceki son adım, her sitedeki host'lar ile witness host arasında bağlantının sağlandığından emin olmak. Bu bağlantıyı yapılandırmadan önce doğrulamak önemli.

vSAN ağı, veri siteleri arasında stretched bir L2 broadcast domain olarak öneriliyor, ama witness appliance'ın vSAN ağına ulaşmak için L3 (routing) gerekiyor. Bu yüzden veri host'ları ile witness arasında static route'lar tanımlanması gerekiyor; ama farklı sitelerdeki veri host'larının birbiriyle iletişimi için bu gerekmiyor, çünkü onlar zaten aynı L2 domain'de.

Bir static route eklemek için kullanılan esxcli komutu manuel'de örnek olarak veriliyor; route bilgisini görüntülemek için ayrı komutlar da mevcut (network komşularını listeleyen ve gateway bilgisini gösteren komutlar). Bu adımın her host için tekrarlanması gerektiği özellikle vurgulanıyor.

Bu kısmı okurken şunu düşündüm: GUI üzerinden yapılan çoğu adımın aksine, bu networking hazırlığı CLI bilgisi gerektiriyor. HOL'da bu adım atlanmış, zaten hazır geliyor, ama gerçek bir kurulumda muhtemelen en çok zaman alacak ve en çok hata yapılacak adım burası olurdu.

Mevcut Cluster'ı Stretched Cluster'a Dönüştürmek

HOL'da var olan 4-node cluster'ı (esx-05a, 06a, 07a, 08a) stretched cluster'a çeviriyoruz. İki host daha (esx-09a, esx-10a) cluster'a ekleniyor, toplam 6 node oluyor.

Host'ları Cluster'a Eklemek

Önce her iki host'ta da (esx-09a ve esx-10a) vSAN VMkernel adaptörünün doğru yapılandırıldığı, Configure > VMkernel Adapters üzerinden kontrol ediliyor.

Ardından host'lar sürükle-bırak ile cluster'a ekleniyor. Açılan onay penceresi varsayılan ayarlarla geçiliyor. Host cluster'a eklendikten sonra, eğer maintenance mode'daysa sağ tık ile Exit Maintenance Mode uygulanıyor. Bu işlem birkaç dakika sürebiliyor, Recent Tasks üzerinden takip edilebiliyor.

Fault Domain Yapılandırması

Asıl dönüşüm burada başlıyor:

cluster-esa-01a > Configure > vSAN > Fault Domains > CONFIGURE STRETCHED CLUSTER

Açılan ekranda host'lar iki domain'e ayrılıyor. Varsayılan olarak hepsi "preferred" tarafında görünüyor; esx-08a, esx-09a ve esx-10a seçilip >> ile secondary domain'e taşınıyor.

Sonraki adımda witness host seçiliyor: esx-11a. vSAN burada otomatik bir uyumluluk kontrolü çalıştırıyor; witness'ın bu cluster ile kullanılabilir olup olmadığını doğruluyor.

Review ekranında vSAN, oluşturacağı cluster konfigürasyonunun özetini gösteriyor; burada, dönüştürme işlemi tamamlanmadan önce düzeltme yapma fırsatı da veriliyor. FINISH ile cluster oluşturuluyor.

İşlem sırasında Recent Tasks panelinden ilerleme izlenebiliyor; tüm görevler "Completed" olana kadar beklemek gerekiyor.

Sonucu Doğrulamak

cluster-esa-01a > Configure > vSAN > Fault Domains ekranına dönüldüğünde:

Failures To Tolerate (FTT) değeri 1 olarak görünüyor. Bu, cluster'ın herhangi bir site'ın (ya da witness host'un) kaybını tolere edip VM'leri çalışır tutabileceği anlamına geliyor.
İki fault domain ve bunlara ait host'lar listede görünüyor.

Manuel'de önemli bir mimari notu var: Site Mirroring ile FTT=1 kombinasyonu, stretched cluster'lar için önerilen standart mimari. 6 node ve üzeri büyük stretched cluster'larda, site içi ek koruma katmanı da isteğe bağlı olarak yapılandırılabiliyor; bu seçimler tipik vSAN politikalarıyla (RAID-1 mirroring, RAID-5 ve RAID-6 erasure coding) uyumlu. Yani site-level koruma ile site-içi koruma birbirinden ayrı, üst üste konumlandırılabilen iki katman.

Nested Ortam Uyarıları

HOL, nested bir vSphere ortamında çalıştığı için vCenter, vSAN cluster'ının sağlığı hakkında birkaç uyarı gösteriyor. Manuel açıkça şunu söylüyor: bu lab kapsamında bu uyarıları görmezden gelmek veya susturmak sorun değil, ama gerçek workload barındıran herhangi bir "canlı" vSAN cluster'ında bu tür uyarıları Skyline Health servisi üzerinden detaylıca araştırmak gerekiyor.

Bu küçük ama önemli bir uyarı; HOL'da görülen "her şey kırmızı/sarı" görünümünün gerçek ortamda aynı ciddiyetle ele alınmaması gerektiğini hatırlatıyor, ama aynı zamanda gerçek ortamda bu uyarıların asla göz ardı edilmemesi gerektiğini de.

Skyline Health: Stretched Cluster'a Özel Kontroller

Cluster oluşturulduktan sonra Skyline Health'te yeni bulgular ortaya çıkıyor. RETEST'e basıldığında "vSAN optimal datastore default policy configuration" başlıklı bir uyarı görülüyor; üç nokta menüsünden TROUBLESHOOT seçilince detaylar açılıyor.

Datastore Default Policy'yi Güncellemek

Cluster yapısı değiştiği için (standart cluster'dan, her sitede üç host olan bir stretched cluster'a geçiş), Skyline Health iki değişiklik öneriyor:

Standart cluster'dan stretched cluster'a (site mirroring ile) geçiş.
Her site içinde RAID-5'ten RAID-1'e geçiş.

"UPDATE Cluster DS Policy" butonuna basılıyor.

Açılan onay penceresinde OK tıklanıyor. Default policy değiştirildiği için, orijinal policy'i kullanan VM'lerin yeni policy'e geçmesi için ayrıca reapply işlemi gerekiyor. Bu ortamdaki VM'ler varsayılan ESA RAID-5 policy'sini kullandığından, policy'yi manuel olarak yeni Optimal Storage Policy'ye değiştirmek gerekiyor.

Mevcut VM'lere Yeni Policy'i Uygulamak

Policies and Profiles menüsüne gidilip yeni oluşan cluster-esa-01a - Optimal Datastore Default Policy - stretched RAID1 policy'si seçiliyor, REAPPLY'a tıklanıyor. Bir uyarı, bu işlemin zaman alabileceğini ve birkaç VM'i etkileyeceğini bildiriyor; OK ile onaylanıyor.

Skyline Health'e dönülüp tekrar RETEST yapıldığında, policy uyarısının kaybolduğu görülüyor. Manuel'de bir not daha var: bazen bu uyarı bir kez daha görünebiliyor, RETEST ile geçiyor.

Stretched cluster'a özel diğer health check'leri görmek için filtre üzerinden "Stretched cluster" kategorisi seçilebiliyor.

vSAN health check, vSAN kurulumlarının performans ve sağlık testlerine derinlemesine inmek için değerli bir araç; vSAN ortamını izlemek için gidilecek ilk yer olmalı. Güncel durumu görmek için health check'i düzenli olarak yeniden çalıştırmak iyi bir pratik.

vSAN Site Affinity: Her VM'in Çok Site Koruması İstemediği Durumlar

Modülün ikinci yarısı farklı bir soruna eğiliyor. Bir veri merkezinde, uygulama seviyesinde zaten dahili yüksek erişilebilirlik veya yedeklilik sağlayan pek çok workload var. Ama tipik production workload'ları çoğunlukla daha iyi veri yedekliliği için çok-site koruması gerektiriyor. Peki, kopyaların farklı sitelerde tutulmasını gerektirmeyen workload'lar için ne yapılabilir?

Bu soruya cevap: Local Affinity.

Local Affinity Mantığı

Local Affinity, bir policy aracılığıyla veriyi tek bir site'da tutmayı sağlıyor. Bunun teknik karşılığı Primary Failures To Tolerate (PFTT) değerinin 0 olarak ayarlanması. PFTT=0 olduğunda nesneler ikincil siteye replike edilmiyor, bu da siteler arası gereken bant genişliğini azaltıyor. Ayrıca affinity kuralları kullanılarak VM/VMDK atamaları belirli host'lara da sabitlenebiliyor.

Manuel, test senaryosu olarak şu kombinasyonu öneriyor: PFTT=0, Secondary Failures To Tolerate (SFTT)=2, Failure Tolerance Method (FTM)=RAID-5. Bu kombinasyonla tüm I/O'nun yerel olarak yapılması, hiçbirinin ikincil siteye gitmemesi bekleniyor. Yani site koruması olmadan, host/disk seviyesinde koruma sorunsuzca elde edilmiş oluyor.

Birkaç kısıtlama da var:

Affinity, sadece Stretched Cluster etkinleştirilmiş cluster'larda kullanılabiliyor.
DRS/HA kuralları, data locality ile uyumlu olmalı.
OSA'da Hybrid konfigürasyonlarda RAID-0 ve RAID-1 destekleniyor, All-Flash'te RAID-0, RAID-1, RAID-5 ve RAID-6 destekleniyor.

Bu son madde aklımda kaldı: Local Affinity kullanılırken DRS/HA kurallarının manuel olarak hizalanması gerekiyor. Bu, "policy ayarladım, iş bitti" diyemeyeceğiniz, cluster'ın diğer otomasyon katmanlarıyla da koordinasyon gerektiren bir özellik.

Single Site Storage Policy Oluşturmak

Policies and Profiles > VM Storage Policies > CREATE

İsim: Single Site Storage Policy. "Enable rules for vSAN storage" seçiliyor.

Availability sekmesinde:

Site disaster tolerance: None - keep data on Preferred (stretched cluster)
Failures to tolerate: 1 failure - RAID-1 (Mirroring)

Datastore uyumluluğu doğrulanıyor (vsan-esa-01a_Datastore Compatible görünmeli), FINISH ile policy tamamlanıyor.

Local Affinity Policy ile VM Oluşturmak

core-a VM'i klonlanarak Local Affinity VM adıyla yeni bir VM oluşturuluyor. Clone wizard'ında:

Datacenter: dc-a
Cluster: cluster-esa-01a
Storage Policy: Single Site Storage Policy
Datastore: vsan-esa-01a_Datastore (compatible olarak görünüyor)

Klon tamamlandığında VM Summary'den policy'nin atandığı ve "Compliant" olduğu doğrulanıyor.

Yerleşimi Doğrulamak: Preferred Fault Domain

cluster-esa-01a > Configure > vSAN > Fault Domains ekranından preferred fault domain'in hangi host'ları içerdiği görülüyor. HOL'daki örnekte esx-05a, esx-06a ve esx-07a preferred domain'de.

Local Affinity VM > Monitor > vSAN > Physical disk placement ekranından, bileşenlerin gerçekten preferred fault domain üzerinde konumlandığı doğrulanıyor.

Bu doğrulama adımı önemli, çünkü policy'nin "doğru göründüğünü" varsaymak yerine bileşenlerin gerçekte nerede oturduğunu kontrol etmek, "compliant" etiketinin arkasındaki gerçekliği teyit ediyor.

Policy'i Değiştirip Site Geçişini Görmek

Modülün son kısmında, Single Site Storage Policy düzenlenerek Site disaster tolerance ayarı "None - keep data on Secondary" olarak değiştiriliyor. Bu, verinin artık preferred yerine secondary site'da tutulmasını söylüyor.

Policy zaten bir VM tarafından kullanıldığı için, "Reapply to VMs" seçeneği "Now" olarak ayarlanıp YES ile onaylanıyor.

Son doğrulama adımında Local Affinity VM > Monitor > vSAN > Physical disk placement tekrar kontrol ediliyor; bu sefer bileşenlerin Secondary Fault Domain'e taşındığı görülüyor.

Bu son adım, Local Affinity'nin sadece statik bir yerleşim olmadığını, policy değiştiğinde verinin gerçekten fiziksel olarak başka bir site'a taşındığını gösteriyor. vMotion gibi VM'in compute'unun taşınması değil, doğrudan storage nesnelerinin yeniden yerleştirilmesi (re-placement) söz konusu.

Genel Değerlendirme

Bu modül, önceki üçünden farklı bir karaktere sahip. SPBM, izleme ve şifreleme tek bir site içinde çalışan kavramlardı. Stretched cluster ise coğrafi/fiziksel bir boyut ekliyor; ağ topolojisi, gecikme süreleri ve "hangi taraf hayatta kalmalı" gibi sorular devreye giriyor.

Benim için en çok düşündüren üç nokta şunlardı:

Birincisi, witness host'un cluster'ın dışında tutulması gerekliliği. İlk bakışta tuhaf geliyor; quorum sağlayan bir bileşenin neden cluster üyesi olmadığını sorgulamak doğal. Ama mantığı şu: witness veri taşımıyor, sadece karar verici. Cluster üyesi olsaydı, kendisi de bir failure noktası haline gelebilirdi.

İkincisi, read locality'nin varsayılan davranış olması ve kapatılmasının neredeyse istisnai bir durum olarak tanımlanması. Bu, "ne zaman varsayılanı değiştirmemeliyim" sorusuna iyi bir örnek; bazen en iyi karar, ayarı olduğu gibi bırakmak.

Üçüncüsü, Local Affinity'nin son demosu; policy değiştiğinde verinin fiziksel olarak taşındığını göstermesi. Bu, SPBM'in sadece "uyumlu/uyumsuz" etiketlemekle kalmadığını, gerçek veri hareketini tetiklediğini somut olarak gösteriyor. Modül 1'de gördüğümüz Placement Details ekranının burada da işe yaraması, serinin kendi içinde nasıl bağlandığını da hissettirdi.

HOL'un nested ortam kısıtlamaları burada daha belirgin hissettiriyor kendini; gerçek bir stretched cluster kurulumunda WAN gecikmesi, bant genişliği sınırlamaları ve gerçek bir site kaybı senaryosu test etmek, bu modülün kapsamının çok ötesinde bir konu. Ama temel kavramları, doğru terminolojiyle ve doğru sırayla görmüş olmak, gerçek bir tasarım dokümanını okurken işe yarayacak bir zemin oluşturuyor.

Bir sonraki hafta Modül 5'e geçiyorum.

Bu seri VMware HOL ortamı (HOL-2634-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production ortamı kararları için mutlaka resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.

vSAN Şifreleme ve Güvenlik: HOL Notları (Modül 3)

Hakan İSMAİL — Sun, 28 Jun 2026 08:59:25 +0000

İki haftadır SPBM ve izleme konularını işledim. Bu hafta Modül 3'e geçiyorum: vSAN şifreleme ve güvenlik. Modül kısa ama içerik yoğun. Şifreleme konuları genelde "evet, şifreleyelim" deyip geçilen yerler değil; anahtar yönetimi, reboot davranışı ve performans etkisi gibi detaylar production'da gerçekten fark ediyor.

Bu yazıda iki ana konu var: data-in-transit (aktarım sırasında) şifreleme ve data-at-rest (durağan veri) şifreleme. İkisi birbirinden bağımsız, ayrı ayrı açılıp kapatılabiliyor.

İki Şifreleme Türü, İki Farklı Amaç

vSAN iki tür şifreleme sunuyor:

Data-in-transit encryption: Host'lar arasında akan tüm vSAN verisi ve metadata trafiğini şifreliyor.

Data-at-rest encryption: Veriyi, deduplikasyon gibi diğer işlemler tamamlandıktan sonra şifreliyor. Bir disk cluster'dan fiziksel olarak çıkarılsa bile üzerindeki veri korunmuş oluyor.

Bu ayrımı net tutmak önemli: birini açmak diğerini otomatik açmıyor. Tehdit modeline göre ikisi farklı senaryoları kapatıyor. Data-in-transit, ağ üzerinde dinleme (sniffing) riskine karşı; data-at-rest, fiziksel disk hırsızlığına veya yanlış imha edilen donanıma karşı.

Data-In-Transit Encryption: Detaylar

Bu özelliğin birkaç teknik özelliği var, not almaya değer:

AES-256 bit şifreleme kullanılıyor.
Data-at-rest şifrelemesiyle ilişkisi yok; ikisi bağımsız açılıp kapatılabiliyor.
Forward secrecy uygulanıyor (yani bir anahtar ele geçirilse bile geçmiş trafiği deşifre etmek için kullanılamıyor).
Data host'ları ile witness host'ları arasındaki trafik de şifreleniyor.
File service trafiği (VDFS proxy ile VDFS server arası) de kapsam içinde.

En dikkat çeken kısım şu: şifreleme için bir Key Management Server'a ihtiyaç yok. Host'lar bir bağlantı kurduklarında dinamik olarak simetrik bir anahtar üretiyor ve bu anahtarla aralarındaki trafiği şifreliyorlar. Bir host cluster'a katıldığında doğrulanıyor, cluster'dan çıkarıldığında ise sertifikası kaldırılıyor.

Bu, data-at-rest şifrelemesine kıyasla operasyonel olarak çok daha hafif bir özellik. Tek bir toggle, anahtar yönetimi derdi yok. Bu yüzden "neden açmayalım ki" sorusuna cevap vermek daha kolay.

Etkinleştirme Adımları

vSphere Client üzerinden:

cluster-esa-01a seçiliyor
Configure
vSAN > Services
Data Services bölümü genişletilip EDIT'e tıklanıyor

Açılan ekranda Data-In-Transit Encryption toggle'ı açılıyor ve APPLY'a basılıyor. Bir de "rekey interval" var; varsayılan 1 gün, ihtiyaca göre özelleştirilebiliyor. Bu rekey periyodu, anahtarların ne sıklıkla yenileneceğini belirliyor.

Data-At-Rest Encryption: Anahtar Hiyerarşisi

Burası modülün biraz daha karmaşık kısmı, ama mantığını anladığınızda aslında oldukça temiz bir tasarım.

Üç seviyeli bir anahtar hiyerarşisi var:

KEK (Key Encryption Key): vCenter, KMS'ten AES-256 bir KEK talep ediyor. Ama vCenter bu anahtarın kendisini saklamıyor, sadece ID'sini tutuyor.

DEK (Data Encryption Key): ESX host, diski AES-256 XTS modunda şifrelerken DEK kullanıyor. OSA'da her disk için ayrı, rastgele üretilmiş bir DEK var. ESA'da ise cluster'daki tüm diskler aynı DEK'i kullanıyor.

Host Key: Core dump'ları şifrelemek için kullanılıyor, veri için değil. Aynı cluster'daki tüm host'lar aynı host key'i paylaşıyor. Support bundle toplarken core dump'lar rastgele bir anahtarla yeniden şifreleniyor; bu anahtara bir şifre de atayabiliyorsunuz.

Burada OSA-ESA farkı dikkatimi çekti. OSA'da disk başına ayrı DEK varken ESA'da tüm cluster için tek bir DEK kullanılması, anahtar yönetimini basitleştiriyor ama "tek anahtar = tek başarısızlık noktası" sorusunu da aklımıza getiriyor. Tabii bu DEK zaten KEK ile şifrelenmiş halde diskte duruyor, host KEK'i almadan DEK'i kullanamıyor; yani anahtarın kendisi tek başına bir şey ifade etmiyor.

Reboot Davranışı: Dikkat Edilmesi Gereken Bir Nokta

Şunu production açısından önemli buluyorum: Host reboot olduğunda, disk grup'ları KEK'i alana kadar mount edilmiyor. Bu işlem birkaç dakika veya daha uzun sürebiliyor. Yani bir host restart sonrası "neden disk grupları hemen görünmüyor" diye panik yapmadan önce, bu sürecin normal olduğunu bilmek gerekiyor. Durumu vSAN health service > Physical disks > Software state health üzerinden takip edebiliyorsunuz.

Bu, KMS'in erişilebilirliğinin de ne kadar kritik olduğunu gösteriyor. KMS'e erişilemiyorsa host KEK'i alamaz, disk grupları mount olmaz. KMS'in yüksek erişilebilirlikli olması bu yüzden boş bir öneri değil.

DISA STIG ve FIPS 140-2

vSAN, vSAN 6.7'den itibaren FIPS 140-2 doğrulamalı ilk yazılım tabanlı çözüm olma iddiasında. vSAN doğrudan hypervisor'a entegre olduğu için vSphere'in kullandığı kernel modülünü kullanıyor ve bu modül FIPS 140-2 doğrulamasına sahip.

Bu, ABD federal hükümeti gibi belirli regülasyon gereksinimleri olan kurumlar için önemli bir kutu işaretleme maddesi. Aynı zamanda DISA onaylı bir STIG'e (Security Technical Implementation Guide) sahip olan ilk HCI çözümü olarak konumlandırılıyor.

Türkiye'deki bir okuyucu için bu spesifik sertifikasyonlar doğrudan bir gereksinim olmayabilir, ama "bu seviyede bir doğrulamadan geçmiş" bilgisi, ürünün güvenlik mimarisinin ne kadar olgun olduğu konusunda bir gösterge.

Key Management Server: Native Key Provider Kurulumu

vSAN encryption, harici bir Key Management Server, vCenter Server ve ESXi host'ları arasında çalışıyor. vCenter, KMS'ten anahtar talep ediyor; KMS anahtarları üretip saklıyor, vCenter ise sadece anahtar ID'lerinin listesini tutuyor.

HOL'da harici bir KMS kurmak yerine vSAN'ın "Native Key Provider" özelliğini kullanıyoruz. Bu, vCenter'a gömülü bir key provider; ayrı bir KMS sunucusu kurmaya gerek kalmıyor.

Kurulum Adımları

vc-mgmt-a.site-a.vcf.lab vCenter'ı seçiliyor
Configure
Security > Key Providers
ADD
Add Native Key Provider

Sonra şu bilgiler giriliyor:

İsim: vSAN-Native-KP
"Use key provider only with TPM..." kutusu işaretsiz bırakılıyor (nested bir lab ortamı olduğu için TPM mevcut değil)
ADD KEY PROVIDER

Key Provider eklendiğinde Type "Native", Status ise "Not backed up" olarak görünüyor.

Yedekleme: Atlanmaması Gereken Adım

Burada gerçekten önemli bir nokta var. Key Provider eklendikten sonra BACK-UP butonuna basıp "BACK UP KEY PROVIDER" seçeneği seçiliyor.

Yedekleme tamamlandığında status "Active" oluyor.

Bu adımın HOL'da bir formalite gibi görünmesi mümkün ama gerçek ortamda kritik: Native Key Provider'ın yedeği yoksa ve vCenter kaybedilirse, şifrelenmiş veriye erişim de kaybedilebilir. "Not backed up" durumundaki bir key provider, encryption'ı aktif etmeden önce mutlaka yedeklenmesi gereken bir uyarı sinyali.

vSAN Encryption'ı Etkinleştirmek

vSAN Encryption, vSAN 6.6'dan beri mevcut ve ilk native HCI şifreleme çözümü olarak tanıtılıyor. Birkaç tıkla tüm vSAN datastore için açılıp kapatılabiliyor; ekstra bir adım gerekmiyor.

Hypervisor seviyesinde çalıştığı için VM'den bağımsız (VM Encryption gibi VM'e özgü değil). Donanımdan bağımsız olduğu için de Self-Encrypting Drive (SED) gibi özel ve daha maliyetli donanımlara ihtiyaç yok.

HOL'da data-at-rest encryption zaten önceden etkinleştirilmiş durumda. Bu bölümde yapılan, "shallow rekey" denilen bir işlem; bu, encryption'ı ilk kez açmakla aynı adımları takip ediyor.

Adımlar

cluster-esa-01a seçiliyor
Configure
vSAN > Services
Data Services altında EDIT

Açılan ekranda:

Data-at-rest Encryption zaten açık görünüyor
Key Provider, nk1'den vSAN-Native-KP'ye değiştiriliyor (her seçenek için bilgi (i) butonuna tıklanarak detay görülebiliyor)
APPLY

İşlem tamamlandığında Data Services genişletilip Key Provider'ın vSAN-Native-KP olarak ayarlandığı doğrulanıyor. Bu noktadan sonra vSAN datastore'a eklenen tüm veri şifreleniyor. Bir anahtar süresi dolarsa veya ele geçirilirse yeni anahtar üretme seçeneği de burada.

Burada dikkatimi çeken şey, bu işlemin "shallow rekey" olarak tanımlanması. Yani mevcut şifrelenmiş veri tamamen yeniden şifrelenmiyor (bu "deep rekey" olurdu, çok daha pahalı bir operasyon); sadece anahtar değişiyor. Production'da deep rekey'in I/O üzerindeki etkisini ayrıca araştırmak gerekir, ama bu HOL bunun ayrımını yapmamıza yardımcı oluyor.

vSAN Encryption Health Check

vSAN, encryption'ın etkin ve sağlıklı olduğunu doğrulamak için health check'lere sahip. Bunlara erişim:

cluster-esa-01a seçili, Monitor
vSAN > Skyline Health
Health findings altında ALL seçiliyor
Category sütunundaki filtre ikonuna tıklanıyor
"Data-at-rest encryption" işaretleniyor

Bu kategoride iki health check var.

Kontrol 1: KMS Bağlantısı

"vCenter and all hosts are connected to Key Management Servers" bulgusunun yanındaki üç noktalı menüden "View Current Result" seçiliyor.

Bu kontrol, ESX Key Provider durumunu, bağlantı durumunu ve anahtar durumunu (key state) listeliyor.

Kontrol 2: AES-NI

Aynı kategori altında "CPU AES-NI is enabled on hosts" bulgusunun üç noktalı menüsünden "View Current Result" seçiliyor.

Bu kontrol, cluster'daki ESX host'ların CPU AES-NI özelliğine sahip olup olmadığını doğruluyor. AES-NI, Intel ve AMD işlemcilerde AES şifreleme/deşifreleme işlemlerini hızlandırmak için tasarlanmış bir donanım uzantısı.

Bu kontrolün burada olması mantıklı: AES-NI olmadan şifreleme yazılımsal olarak yapılır ve bu CPU üzerinde belirgin bir yük oluşturur. Modern sunucu işlemcilerinin büyük çoğunluğunda AES-NI zaten var, ama eski donanımla çalışan ortamlarda bu kontrolün kırmızı çıkması, "şifrelemeyi açtık ama performans neden düştü" sorusunun cevabı olabilir.

Genel Değerlendirme

Bu modül, önceki ikisine göre daha "arka plan" bir konuyu işliyor; şifreleme açıldıktan sonra günlük operasyonda görünür bir şey değişmiyor, ama yanlış yapılandırıldığında ya da KMS erişilemez olduğunda etkisi çok görünür hale geliyor.

Benim için en dikkat çekici üç nokta şunlardı:

Birincisi, data-in-transit encryption'ın KMS gerektirmemesi ve tamamen dinamik anahtarlarla çalışması. Bu, "açmamak için bahane bulmak zor" bir özellik; operasyonel yük neredeyse sıfır.

İkincisi, host reboot sırasında disk gruplarının KEK'i bekleyerek mount olması. Bu, KMS'in yüksek erişilebilirlik gereksinimini soyut bir "best practice" maddesinden çıkarıp somut bir bağımlılığa dönüştürüyor. KMS düşerse, sadece yeni anahtar talepleri değil, reboot sonrası disk mount süreçleri de etkileniyor.

Üçüncüsü, Native Key Provider'ın "Not backed up" uyarısı. HOL'da bu adım hızlıca geçiliyor ama gerçek bir ortamda bu, encryption'ı açmadan önce check-list'in en üstünde olması gereken bir madde gibi duruyor.

vSAN'ın şifreleme tarafı, "aç ve unut" gibi pazarlanıyor ve büyük ölçüde de öyle. Ama anahtar yönetimi her zaman böyle; basit görünen arayüzün ardında, bir şeyler ters gittiğinde önemli hale gelen bir bağımlılık zinciri var.

Bir sonraki hafta Modül 4'e geçiyorum.

vSAN İzleme: Sağlık, Kapasite ve Performans: HOL Notları (Modül 2)

Hakan İSMAİL — Sun, 21 Jun 2026 07:20:16 +0000

Geçen hafta SPBM'i, policy yönetimini ve cluster'ı büyütüp küçültmeyi incelemiştim. Bu hafta Modül 2 ile devam ediyorum. Konu: vSAN ortamının sağlığını izlemek, kapasiteyi takip etmek ve performans verilerini okumak.

Bu modül biraz farklı bir yerden başlıyor. Bir şey kurup yapılandırmak yerine, kurulu ortamı "gözetlemeyi" öğreniyoruz. Kulağa pasif geliyor ama değil; hangi ekrana ne zaman bakacağını bilmek, bir sorun çıktığında saatleri kurtarabilir.

vSAN Health Check: Neden Önemli?

vSAN 6.0'dan bu yana sistemde yerleşik bir sağlık kontrol mekanizması var. Yüzden fazla hazır kontrol içeriyor. Ağ bağlantısı, donanım uyumluluğu, disk durumu, VM nesneleri, konfigürasyon tutarsızlıkları gibi başlıkları kapsıyor.

Yeni bir cluster kurduktan sonra yapılacak ilk şeylerden biri bu kontrolü çalıştırmak. Bir ağ sorununu erkenden yakalamak ile haftalar sonra performans şikayetleri gelince fark etmek arasındaki farkı bu araç belirleyebilir.

Skyline Health Üzerinden Kontrol

vSphere Client'ta şu yola gidiyoruz:

cluster-esa-01a > Monitor > vSAN > Skyline Health

Açılan ekranda üç şey görüyorsunuz:

Cluster Health Score (sayısal bir puan)
Health Score Trend (zaman serisi)
Health Findings (aktif sorunlar)

Trend görünümünde "VIEW DETAILS" diyince geçmişe de bakabiliyorsunuz; sorunun ne zaman başladığını görmek için işe yarıyor.

Kontrolleri kategoriye göre filtrelemek de mümkün. "Category" filtresinden "Network" seçince sadece ağ katmanıyla ilgili testler listeleniyor. Her testin yanındaki >> ikonuna tıklayınca sağ panelde o kontrolün ne anlama geldiği ve nasıl düzeltileceği açıklıyor. KB makalesi bağlantısı da genellikle orada.

Kasıtlı Arıza: Sistemi Test Etmek

HOL'un bu kısımda yaptığı ilginç: bir host'u kasıtlı olarak disconnect edip health check'in bunu nasıl yakaladığını gösteriyor.

esx-05a.site-a.vcf.lab üzerine sağ tık, Connection > Disconnect diyoruz. Ardından Skyline Health'e dönüp RETEST'e basıyoruz.

Birkaç saniye içinde "UNHEALTHY" bölümünde esx-05a'nın vCenter'dan koptuğuna dair uyarı çıkıyor. TROUBLESHOOT'a basınca hangi host'un sorunlu olduğu, durumu ve KB bağlantısı görünüyor.

Sonra aynı host'u yeniden connect edip RETEST yapıyoruz. Uyarı kayboluyor, health score normale dönüyor.

Bu adımın değeri şu: Sistemin gerçekten alarm üretip üretmediğini, doğru kaynağı gösterip göstermediğini ve çözüm önerisi sunup sunmadığını ellerin kirletmeden görmek.

Kapasite İzleme

Kapasite takibi için birkaç farklı giriş noktası var. En doğrudan olanı datastore görünümü.

Datastores Icon > dc-a > vsan-esa-01a_Datastore > Summary > VIEW CAPACITY

Açılan ekranda iki önemli bölüm var:

Capacity Overview: Toplam kapasite, kullanılan alan ve boş alan. Standart bir disk kullanım göstergesi.

What-if Analysis: Burası daha ilginç. Seçtiğiniz bir storage policy bazında "etkin boş alan" hesaplıyor. Thin provisioning açısından datastore'un oversubscribed olup olmadığını da gösteriyor. Yani gerçek fiziksel alan ile politika gereği ayrılması gereken alan arasındaki farkı görünür kılıyor.

Kullanım Detayı (Usage Breakdown)

"EXPAND ALL" diyince vSAN datastore üzerindeki nesne tiplerinin dökümü geliyor:

VMDK'lar (sanal diskler)
VM Home namespace'leri
Swap nesneleri
Performans servisi veritabanı
Dosya sistemi ve checksum overhead
Diğerleri (template, ISO gibi kategorize edilmemiş nesneler)

Yüzdeler anlık kullanıma göre değişiyor. Ortam henüz az doluysa overhead kalemleri orantısız büyük görünebiliyor; bu normal.

Performans İzleme

vSAN'ın yerleşik performans servisi vSAN 9 ile cluster seviyesinde otomatik olarak aktif geliyor. Bu servis her host üzerinde çalışıyor, veri topluyor ve sonuçları vSAN datastore üzerinde ayrı bir nesne olarak saklıyor.

Birkaç detay kayda değer:

Metrikler 90 gün saklanıyor.
5 dakikalık aralıklarla kaydediliyor.
Performans veritabanı vCenter'dan bağımsız bir vSAN nesnesi. vCenter erişilemez olsa bile veriler orada duruyor, ama görüntüleyemezsiniz.
Veritabanına da bir storage policy atanmış; bu nedenle "Configure > vSAN > Services > Performance Service" altında Stats DB'nin Compliant olduğunu görebilirsiniz.

Üç Seviyede Performans Görünümü

Performans verilerini üç farklı seviyede inceleyebiliyorsunuz:

Cluster Seviyesi

cluster-esa-01a > Monitor > vSAN > Performance

Burada VM, Backend, File Share ve IOInsight sekmelerini göreceksiniz. Önemli bir ayrım var:

"Front-end" trafik: VM'lerin doğrudan oluşturduğu okuma/yazma trafiği.
"Back-end" trafik: Replika ve senkronizasyon trafiği; vSAN VMkernel arayüzü üzerinden akıyor. Bu iki trafiği ayrı izlemek, bir yavaşlamanın VM'den mi yoksa vSAN'ın arka plan operasyonlarından mı kaynaklandığını anlamak için gerekli.

Host Seviyesi

esx-05a.site-a.vcf.lab > Monitor > vSAN > Performance

Cluster görünümüne kıyasla daha fazla sekme var: VM, Backend, Disks, Physical Adapters, Host Network ve I/O Insight. Bir performans sorununun hangi katmandan geldiğini daraltmak için bu seviye daha kullanışlı.

VM Seviyesi

acct-app-01 > Monitor > vSAN > Performance

Sanal disk bazında IOPS, throughput ve latency. Belirli bir VM'den şikayet geldiğinde buradan başlamak doğru.

VCF Operations ile Çok Cluster İzleme

Şimdiye kadar gördüklerimiz vCenter içindeydi ve tek cluster'a bakıyordu. Birden fazla cluster'ı, birden fazla workload domain'i izlemek gerektiğinde VCF Operations devreye giriyor.

HOL'da yeni bir sekmede VCF Operations'a giriş yapıyoruz:

Infrastructure Operations > Storage Operations

Storage Operations: Ne Görünüyor?

Ekran üç katmanda bilgi sunuyor:

Üst kısım:

Storage Alert Trends: Tüm storage instance'larında kaç uyarı var.
Usage and Distribution: vSAN ve vSAN dışı storage'ları kapsayan toplam/boş kapasite.

Orta kısım:

vSAN Cluster Health Score: Tüm cluster'ların Skyline health skoru bir arada.
vSAN Cluster Types: HOL ortamında ne var ne yok görünüyor: 1 ESA cluster, 2 OSA cluster, 1 Storage Cluster, 1 Compute Cluster. Bu dağılım modül bazlı hangi konuların ayrı cluster türleri gerektirdiğini göstermesi açısından da ilginç.
vSAN Cluster Performance: Tüm cluster'ların IOPS, throughput ve latency değerleri; tek ekranda.

Alt kısım: Cluster bazında daha granüler metrikler.

Hazır Dashboard'lar

Dashboards & Reports menüsüne geçip arama kutusuna "vsan" yazınca hazır dashboard listesi çıkıyor. "vSAN ESA Performance" dashboard'unu açıp bir cluster seçince IOPS, latency ve throughput verilerini görselleştirilmiş halde görüyorsunuz.

Bu dashboard'ların önemli bir özelliği var: VCF Operations içinde tek bir cam yüzeyi sunuyorlar. vCenter'da cluster cluster dolaşmak yerine buradan konsolidasyon yapılabiliyor.

Genel Değerlendirme

Bu modül bir öncekinden farklı bir kas grubu çalıştırıyor. Kurulum ve yapılandırma değil, okudum anlama.

Bir şey dikkat çekti: vSAN'ın izleme araçları birbiriyle iç içe geçmiş ama her biri farklı bir soruya cevap veriyor. Skyline Health "sorun var mı" sorusu için. Kapasite ekranı "ne kadar yerim kaldı ve bu yeter mi" için. Performans servisi "sistem iyi çalışıyor mu, darboğaz nerede" için. VCF Operations ise bu üçünü birden tek pencerede görmek ve birden fazla cluster'ı karşılaştırmak için.

Gerçek ortamda bu ayrımı bilmeden izleme yapmak, doğru araçla yanlış soruyu sormak anlamına gelebilir. Mesela kapasite doluyken performans grafiklerine bakmak, asıl problemi kaçırmanıza neden olabilir.

Bir diğer gözlem: Performans veritabanının vCenter'dan bağımsız bir vSAN nesnesi olarak depolanması teorik olarak temiz bir tasarım. Ama bu nesne erişilemez hale gelirse performans geçmişine de ulaşamazsınız. Production'da bu nesnenin politikasını ve sağlığını ayrıca takip etmek gerekiyor; HOL'da bunu görüp not aldım.

Bir sonraki hafta Modül 3'e geçiyorum: vSAN şifreleme ve güvenlik.

VMware vSAN ile Başlarken: Depolama Politikası, Kullanılabilirlik ve HOL Notları (Modül 1)

Hakan İSMAİL — Sat, 13 Jun 2026 17:36:05 +0000

Birkaç haftadır "VMware vSAN - Getting Started and Advanced Topics" başlıklı HOL (Hands-on Lab) üzerinde çalışıyorum. Bu yazı, o serinin ilk modülünden çıkardığım notların ve gözlemlerin bir dökümü. Baştan söyleyeyim: burada anlatılanlar gerçek bir üretim ortamından değil, tamamen HOL ortamından geliyor. Kendi adıma bu ayrımı net tutmak önemliydi çünkü sahadaki dinamikler ile simüle bir ortam arasında her zaman fark var. Ama bu fark, HOL'u değersiz kılmıyor; tam tersine, kavramları karşılıklı test edip yanılma maliyeti sıfır olarak görmek için iyi bir zemin.

Şimdi Modül 1'de neyle karşılaştığımı aktarayım.

Ortam Hakkında Kısa Bir Not

Lab iki siteden oluşuyor: Site A ve Site B. İlk dört modül tamamen Site A üzerinde ilerliyor. Yönetim cluster'larına dokunulmaksızın sadece workload cluster'larında çalışıyoruz. Bu ayrım, özellikle VCF (VMware Cloud Foundation) bağlamında düşününce mantıklı: yönetim katmanına gereksiz yandan temas, gerçek ortamlarda da kaçınılan bir şey.

vSAN Nedir, Neden Var?

vSAN 2014'te hayatımıza girdi. Temel fikir şu: birden fazla ESXi host'unun yerel disklerini bir araya getirip tek, merkezi olarak yönetilen bir depolama havuzu oluşturmak. Ayrı bir storage donanımına gerek kalmıyor, en azından teoride.

Bunun anlamı şu: vSAN doğrudan vSphere hypervisor'ına gömülü. Yani bir storage OS yönetmiyorsunuz, ayrı bir SAN fabric kurmuyor değilsiniz. Compute ve storage, vSphere Client üzerinden tek elden yönetiliyor. TCO açısından geleneksel storage'a kıyasla yüzde elliye varan maliyet düşüşü iddiası var. Bunu elbette ortam büyüklüğüne, lisans yapısına ve mevcut altyapıya göre ayrı değerlendirmek gerek, ama kavramsal olarak mantığı oturuyor.

Data resilience tarafında erasure coding (silme kodlaması) kullanılıyor. RAID-5 ve RAID-6 burada saf disk mirroring'e göre daha verimli kapasite kullanımı sağlıyor.

vSAN 9'da Neler Değişti?

Bu HOL, vSAN 9 üzerine kurulu. vSAN 9'da öne çıkan başlıklara bakmak istedim çünkü önceki sürümlerle karşılaştırma yapmadan nelerin "yeni" olduğunu anlamak zor.

Gerçek hayatta şunu sormak gerekir: mevcut donanımınız ESA'yı destekliyor mu? ESA'nın VMware HCL gereksinimleri daha kısıtlayıcı. Bu, HOL'da görmediğiniz ama sahaya geçince sizi ilk duraksatan şeylerden biri olabilir.

VMware Live Recovery ile DR

vSAN cluster'ları artık VMware Live Recovery entegrasyonuyla korunabiliyor. RPO 1 dakikaya kadar inebiliyormuş. Bu özellik Modül 7'de işleniyor, burada sadece genel bir bilgi olarak geçiyor.

File Services ve Kubernetes

vSAN artık Kubernetes pod'ları için file-based persistent volume destekliyor. Aynı zamanda cluster başına 500 adet file share'e kadar çıkılabiliyor (vSAN 9 ile gelen bir iyileştirme). Bu konu Modül 6'da detaylandırılıyor.

Dying Disk Handling (DDH)

ESA'da disk latency değerlerini izleyip önceden belirlenen eşik aşılırsa otomatik müdahale edebiliyor. Cache drive arızalarını da proaktif olarak yakalıyor. Bu tür şeyler production ortamında görünmez çalışmasını beklediğiniz mekanizmalar; genelde var olduğunu ancak bir sorun çıktığında fark ediyorsunuz.

Global Deduplication (Sınırlı Yayın)

OSA'da deduplikasyon alanı disk grubuyla sınırlıydı. ESA ile bu kapsam tüm cluster'a genişliyor; tekrar eden bloklar cluster genelinde tek depolama ihtiyacına düşüyor. Veri azaltma oranları teorik olarak daha iyi. VCF 9.0 P01 ile TQR programı kapsamında geliyor.

Storage Policy Based Management (SPBM)

Bu modülün asıl konusu SPBM. Burada anlatmak istediğim şeyin "politika" kısmına takılmamak lazım; bu bir kurumsal yazılım sloganı değil, gerçekten işe yarayan bir mekanizma.

Temel mantık şu: VM'e "şu datastore'a yerleştir" demiyorsunuz. Onun yerine bir politika tanımlıyorsunuz, "bu VM en az 1 arıza tolere edebilmeli, RAID-5 ile" gibi. vSAN bu politikaya uyan yerleşimi kendisi buluyor. VM o politikaya uymakta zorlanırsa bunu da raporluyor: "Compliant" ya da "Non-compliant."

Bu yaklaşım, özellikle büyük ortamlarda her VM için ayrı ayrı storage konfigürasyonu yapmak yerine politika bazlı bir standart getiriyor. Dezavantajı şu olabilir: politika sayısı artınca bunları kim/ne zaman güncelleyecek, eski politikalara kim sahip çıkacak sorularına önceden cevap vermek gerekiyor.

Default Policy ve Optimal Datastore Default Policy

vSAN'ın bir "default storage policy"si var. Bu, herhangi bir politika atanmadan oluşturulan VM'lere otomatik atanıyor. Bunu silemiyorsunuz, ama kopyalayıp üzerine kendi politikanızı kurabiliyorsunuz.

vSAN 8.0 U1 ile gelen "Auto-Policy Management" özelliği ise bunu bir adım öteye taşıyor. Cluster'daki host sayısına ve konfigürasyonuna bakarak size özel bir "cluster-esa-01a - Optimal Datastore Default Policy - RAID5" gibi bir politika oluşturuyor. Bu otomatik politika RAID seviyesini cluster büyüklüğüne göre belirliyor. HOL'da bu özellik zaten etkin hale getirilmiş.

İlk Uygulama: VM Deploy Etmek

Bu bölümde mevcut bir VM'i (core-a) vSAN datastore'a klonluyoruz. Adımlar gayet açık:

vSphere Client'tan VM'e sağ tık → Clone → Clone to Virtual Machine
İsim: clone-vm-a
Cluster: cluster-esa-01a
Datastore: vsan-esa-01a_Datastore
Storage Policy: cluster-esa-01a - Optimal Datastore Default Policy - RAID 5

Klon işlemi tamamlanınca VM Summary ekranından politikanın atanmış ve "Compliant" olduğunu doğrulamak mümkün.

VM vSAN Üzerinde Nasıl Depolanıyor?

Bu kısım bence modülün en ilginç parçası. vSAN ESA'nın log-structured file system mimarisine bakınca şunu görüyorsunuz:

Yazma işlemi iki aşamada gerçekleşiyor:

Performance Leg (RAID-1): Gelen yazma önce RAID-1 olarak iki host arasında mirroring ile saklanıyor. Hızlı write acknowledgement için. Veri henüz kalıcı konumuna geçmedi.

Capacity Leg (RAID-5 veya RAID-6): Küçük yazmaların yeterince birikmesiyle vSAN bunları full-stripe write olarak RAID-5/6 formatında kalıcı kapasiteye indiriyor (destage). Bu, IO amplifikasyonunu azaltmak için tasarlanmış.

HOL'da bunu "Monitor > vSAN > Virtual Objects" üzerinden görebiliyorsunuz. VM'in hard diskini seçip "View Placement Details"e tıklayınca bileşenlerin hangi host üzerinde bulunduğunu görüyorsunuz.

Bu dağılımı görmek, "storage siyah bir kutu" algısını kırıyor. Veriyi görünür kılıyor.

Cluster'ı Büyütmek: Scale Out

RAID-5 ve RAID-6 için host sayısı gereksinimleri önemli:

Mimari	RAID-5 Minimum	RAID-6 Minimum
OSA	4 host	6 host
ESA	3 host (2+1 şeması, 1.5x kapasite)	6 host

ESA'da 6 veya daha fazla host varsa RAID-5 şeması 4+1'e geçiyor ve kapasite verimliliği artıyor (1.25x). Bu geçiş host sayısı değiştikten 24 saat sonra otomatik.

Yeni Host Eklemek

HOL'da cluster başlangıçta 4 host ile geliyor. İki ek host (esx-09a ve esx-10a) dışarıda bekliyor. Bu host'ları sürükle-bırak ile cluster'a ekliyorsunuz.

ESA'da artık "disk group" kavramı yok. Onun yerine "disk pool" var; host üzerindeki tüm uyumlu sürücüler havuza dahil oluyor. "vSAN Managed Disk Claim" etkinse eklenen host'un uyumlu sürücüleri otomatik olarak algılanıp vSAN datastore'a dahil ediliyor. HOL'da bu özellik etkin.

Disk Management: eklenen host'un sürücüleri" width="800" height="339">

Skyline Health ve Otomatik Policy Önerisi

İki host eklendikten sonra Skyline Health'i açtığımızda bir uyarı görüyoruz: cluster 6 host'a çıktığı için Auto Policy Management yeni bir politika öneriyor.

"TROUBLESHOOT" dediğinizde mevcut politika (RAID-5) ile önerilen politika (RAID-6) yan yana görünüyor. Mantıklı: 6 host ile RAID-6 hem mümkün hem daha resilient.

"UPDATE CLUSTER DS POLICY" diyebilirsiniz; bu noktadan sonra oluşturulan VM'ler RAID-6 politikası alıyor. Mevcut VM'leri de Policies and Profiles > REAPPLY ile güncelleyebiliyorsunuz. HOL'da bu adım zaman kazanmak için atlanıyor.

İleri Düzey Policy: Compression'ı Kapatmak

ESA'da sıkıştırma (compression) artık storage policy seviyesinde yönetiliyor. Varsayılan olarak açık, çünkü replica trafiği de compressed olarak taşınıyor. Ama bazı durumlarda kapatmak gerekebilir: kendi sıkıştırmasını yapan uygulamalar (veritabanları gibi) için ekstra sıkıştırma hem CPU israfı hem de veri azaltma oranlarını yanıltabilir.

Bu bölümde şunu yapıyoruz:

Mevcut vSAN ESA Default Policy - RAID5 politikasını klonla.
Yeni politikaya isim ver: vSAN ESA No Compression - RAID 5
Storage rules > Storage tier: "No space efficiency" seç (sıkıştırma bu şekilde devre dışı kalıyor)
Uyumluluk kontrolü: vsan-esa-01a_Datastore compatible göründüğünü doğrula
Finish

Ardından mevcut clone-vm-a VM'ine bu yeni politikayı atıyoruz: VM > Configure > Policies > EDIT VM STORAGE POLICIES. Dropdown'dan yeni politikayı seçince bir süre sonra VM "Compliant" statüsüne geçiyor.

Reserved Capacity

vSAN'ın tüm kapasitesi varsayılan olarak workload'lara açık. Ama cluster'da bir rebuild veya rebalancing operasyonu başladığında o an doluysa ne olacak? İşte "Reserved Capacity" tam buna yönelik.

İki tür rezervasyon var:

Operations Reserve: Cluster içi operasyonlar (policy reconfig, vb.) için ayrılan alan.

Host Rebuild Reserve: Bir host arızalandığında veri yeniden inşası için ayrılan alan. Bu rezervasyon, cluster'daki en büyük host'un kapasitesine göre belirleniyor. Minimum 4 host gereksinimi var.

HOL'da bu özelliği etkinleştirme ekranını görüyoruz: uyarı eşikleri %70, hata eşikleri %90 olarak ayarlanmış. Sonra iptal ediliyor çünkü iç içe geçmiş (nested) lab ortamında gerçek anlamda reserve etmek için yeterli kapasite yok.

Bu noktada şunu düşünmeden geçemedim: gerçek ortamlarda bu rezervasyonu kurmak ne zaman anlam taşıyor? Disk kapasitesi kısıtlıysa reserve etmek kısa vadede sizi zorlar. Ama o buffer olmadan bir host çöktüğünde rebuild yetersiz kapasiteye çarpar, bu daha büyük bir risk. Denge kurmak gerekiyor.

Bir kısıtlama notu: Stretched cluster, fault domain kullanılan cluster'lar, ROBO cluster ve 4'ten az host içeren cluster'larda bu özellik desteklenmiyor.

Scale In: Node Çıkarmak

Scale out kadar konuşulmayan ama production'da bir o kadar önemli olan şey: cluster'ı küçültmek. vSAN cluster'ı minimum 3 host ile çalışır. Host çıkarmadan önce şunlara bakmak gerekiyor:

Kalan compute ve storage kapasitesi yeterli mi?
Mevcut VM storage policy'leri compliant kalmaya devam edecek mi?

Data Migration Pre-Check

Bu araç, "şu host'u çıkarsam ne etkilenir?" sorusunun cevabını veriyor. HOL'da esx-10a seçilip "Full data migration" tercih edildiğinde hiçbir nesnenin etkilenmeyeceği görülüyor. Ardından direkt "ENTER MAINTENANCE MODE" adımına geçilebiliyor.

Maintenance Mode ve Host Kaldırma

Maintenance mode'a alınan host sonra drag & drop ile cluster dışına (datacenter seviyesine) taşınıyor. Aynı adımlar esx-09a için de tekrarlanıyor. Cluster böylece 4'e iniyor.

Genel Değerlendirme

HOL formatı bu konu için iyi çalışıyor. Her adım ekran yönlendirmesiyle geldiği için "nerede tıklamalıyım" sancısı yaşamıyorsunuz; odağınız tamamen mantığı anlamaya kayıyor. Ama şunu da söylemeliyim: HOL sizi hiçbir şeyin bozulmadığı, kapasitesinin üstünde çalışmayan bir ortamda karşılıyor. Gerçek sahada bu adımların her birinin yanına "peki bunu değişken bir ortamda nasıl yapacaksın, işler ters giderse ne olur" soruları ekleniyor.

Modülün beni en çok düşündüren kısmı RAID şeması geçişleri ve bunların kapasite verimliliğine yansımaları oldu. ESA'nın adaptif RAID-5'i (3-5 host için 1.5x, 6+ host için 1.25x) storage planlaması açısından gerçekten önemli bir ayrıntı. Host ekledikten 24 saat sonra otomatik geçiş yapması şık, ama o 24 saatte neler olabileceğini de takip etmek gerekir.

Bir sonraki haftada Modül 2'ye; sağlık izleme, kapasite takibi ve performans raporlaması konularına geçeceğim.

Local LLM Ops: Building an Observable, GPU-Accelerated AI Cloud at Home with Docker & Grafana

Hakan İSMAİL — Fri, 13 Feb 2026 19:50:35 +0000

Why I Built My Own Local AI Stack: Prioritizing Privacy & ROI

Integrating AI into a development workflow usually starts with a compromise: you either send your proprietary code to a third-party API (risking Data Privacy and Compliance) or you watch your "pay-per-token" bill spiral out of control (Operational Overhead).

As a Systems Administrator, I prefer a third option: Data Sovereignty. I wanted a private, secure, and fully observable AI environment, eliminating data leak risks (GDPR/KVKK compliance) while achieving significant Long-term ROI by running on my own hardware (Arch Linux + NVIDIA RTX 3050 Ti).

The real challenge wasn't just downloading an LLM; it was engineering a Scalable AI Infrastructure that runs efficiently on consumer hardware. I'm documenting how I orchestrated this microservices-based stack with Docker Compose, optimized Resource Management for limited VRAM, and established Full-Stack Observability with Grafana and Prometheus.

Scalable Microservices Architecture

I went with a modular, containerized approach to ensure internal Scalability and keep the host system clean:

Inference Management: Ollama
Secure Hardware Integration: NVIDIA Container Toolkit
User Experience (UX): OpenWebUI (for a polished RAG-capable interface).
The Observability Layer:
- NVIDIA DCGM Exporter for real-time hardware telemetry.
- Prometheus & Grafana for SLA monitoring and data retention.

Infrastructure & GPU Passthrough

Before deploying the containers, we must ensure the host operating system (Arch Linux in my case) allows Docker to access the GPU hardware. This is not enabled by default.

1.1 The Prerequisites: NVIDIA Container Toolkit

The bridge between Docker containers and the physical GPU is the NVIDIA Container Toolkit. Without this, the containers would only see the CPU, resulting in painfully slow inference speeds (0.5 tokens/sec).

Since I am running Arch Linux, the setup was straightforward:

# Install the toolkit
sudo pacman -S nvidia-container-toolkit

# Configure the Docker daemon to use the NVIDIA runtime
sudo nvidia-ctk runtime configure --runtime=docker

# Restart Docker to apply changes
sudo systemctl restart docker

To verify the passthrough is working, I ran a quick ephemeral container. If nvidia-smi prints the GPU stats inside Docker, we are green.

docker run --rm --gpus all nvidia/cuda:12.4.1-runtime-ubuntu22.04 nvidia-smi

Container Orchestration

I believe in "defining once, running everywhere." Instead of running disparate docker run commands, I defined the entire stack in a single docker-compose.yml file.

This file handles network isolation (creating a private ai-net), volume persistence (so our chat history isn't lost on reboot), and most importantly, GPU resource reservation.

Here is the complete configuration:

services:
  # 🧠 1. AI ENGINE: Ollama
  # This is the backend that runs the LLM inference.
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_storage:/root/.ollama
    # Critical: This section reserves the NVIDIA GPU for this container
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: unless-stopped
    networks:
      - ai-net

  # 💻 2. INTERFACE: OpenWebUI
  # A user-friendly frontend that connects to Ollama.
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - openwebui_storage:/app/backend/data
    depends_on:
      - ollama
    restart: unless-stopped
    networks:
      - ai-net

  # 🕵️ 3. METRICS EXPORTER: NVIDIA DCGM
  # This container scrapes GPU metrics (Temp, Power, Utilization).
  dcgm-exporter:
    image: nvidia/dcgm-exporter:latest
    container_name: dcgm-exporter
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    environment:
      - DCGM_EXPORTER_NO_HOSTNAME=1
    ports:
      - "9400:9400"
    restart: unless-stopped
    networks:
      - ai-net

  # 🗄️ 4. TIME-SERIES DB: Prometheus
  # Collects the metrics exposed by dcgm-exporter.
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
    restart: unless-stopped
    networks:
      - ai-net

  # 📊 5. VISUALIZATION: Grafana
  # Displays the metrics in a dashboard.
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3001:3000"
    volumes:
      - grafana_storage:/var/lib/grafana
    restart: unless-stopped
    networks:
      - ai-net

volumes:
  ollama_storage:
  openwebui_storage:
  prometheus_data:
  grafana_storage:

networks:
  ai-net:
    driver: bridge

Prometheus Scraper Configuration

Prometheus needs to know exactly where to pull metrics from. I configured a 5-second scrape_interval. While 15s-30s is more common for production, a 5s interval is better for a local lab where we want to track immediate power spikes during token generation.

global:
  scrape_interval: 5s # Scrape often for real-time visibility

scrape_configs:
  - job_name: "gpu-metrics"
    static_configs:
      - targets: ["dcgm-exporter:9400"]

With the configuration files in place, a single command boots the entire cloud infrastructure:

docker compose up -d

Resource Management: Optimizing for 4GB VRAM

The infrastructure setup is the foundation, but Cost-Sensitive Resource Allocation, selecting a model that runs effectively on limited hardware, is where the real value lies. I optimized this build for an NVIDIA RTX 3050 Ti with 4GB of VRAM.

The VRAM Constraint

Popular models like DeepSeek R1 or Llama 3 (8B) usually require 5GB to 6GB of VRAM just to load. Offloading these models to system RAM via PCIe on a 4GB card results in unusable generation speeds, often dropping to 1-2 tokens per second.

I needed a model that fits entirely within the 4GB ceiling while remaining capable for coding tasks.

Choosing the right model: Qwen 2.5 Coder (3B)

I used Hugging Face to cross-reference benchmarks and VRAM requirements for various 1B, 3B, and 7B models. After evaluating the trade-offs between parameter count and inference speed, I settled on Qwen 2.5 Coder (3B Instruct).

Since it only occupies roughly 2.2 GB of VRAM, it leaves enough headroom for the context window without triggering a bottleneck. It's significantly faster than larger models that would force the system to swap to system RAM.

I specifically used the Instruct version; it's much better at actual code logic than the base model.

You can pull it with:

docker exec -it ollama ollama run qwen2.5-coder:3b

Verifying Telemetry

Once the containers are up, query the DCGM exporter directly to ensure the GPU is communicating correctly with Docker:

curl http://localhost:9400/metrics

You'll see keys like DCGM_FI_DEV_GPU_TEMP and DCGM_FI_DEV_POWER_USAGE. Now we need to visualize these in Grafana.

Dashboard Configuration

Since Grafana and Prometheus are on the same Docker network (ai-net), they communicate via container names.

Log in to Grafana (http://localhost:3001, default admin/admin).
Add Prometheus as a data source and use the URL: http://prometheus:9090.

Import Dashboard ID 12239 (NVIDIA DCGM Exporter).

The result is a comprehensive command center for your local AI hardware.

Real-World Business Value & Metrics

I tested the stack with a typical DevOps automation request:

"Write a bash script that detects zombie processes and logs the action."

Full-Stack Observability Analysis

Checking the Grafana dashboard during inference gives the ultimate validation of the setup, proving System Reliability:

VRAM Efficiency: Usage peaked at 2.8 GB. This confirms that the 3B model is the sweet spot: fluent generation with Zero Licensing Overhead.
Scalability Benchmarks: ~438 prompt tokens/s and ~10 generation tokens/s. Proving that high-performance AI is possible without cloud dependency.

Operational Sustainability: The GPU pulled a steady 20W and stayed at 64°C. This is a Low-Cost/High-Performance local solution.

Summary: Driving Innovation Internally

Building a local AI stack isn't just a technical exercise; it's a strategic move for Business Continuity and Data Security. By combining Docker, NVIDIA's toolkit, and a comprehensive observability layer, I've created a dev environment that's both secure and cost-efficient, proving that significant AI ROI can be achieved on existing on-premise hardware.

Dijital Mahremiyeti Geri Kazanmak: Pi-hole, Unbound ve Tailscale ile Gözetimsiz İnternet

Hakan İSMAİL — Wed, 28 Jan 2026 15:44:13 +0000

Giriş

Bir Sistem Mühendisi için en büyük israf, atıl duran işlem gücüdür. Çekmecemde uzun süredir "kış uykusunda" olan Raspberry Pi 3'e baktığımda, sadece eski bir devre kartı değil, potansiyel bir ağ savunma hattı görüyordum.

İnternet Servis Sağlayıcımın (ISS) şeffaf olmayan DNS yönlendirmeleri ve evdeki Akıllı TV’min, ben kullanmasam bile arka planda Google sunucularına telemetri verisi gönderme çabası artık bardağı taşırmıştı.

Ev ağım, benim kontrolümde olması gereken özel bir alanken, adeta büyük şirketlerin veri madenciliği sahasına dönüşmüştü. Çözüm, o çekmecedeki atıl donanımı aktif ve tavizsiz bir ağ geçidine dönüştürmekte yatıyordu.

Amacım netti: Kurumsal ağlarda uyguladığımız "Zero Trust" prensibini ev ölçeğine taşımak. Hiçbir cihazın, benim iznim olmadan "Big Tech" sunucularına veri göndermediğinden emin olmak ve bunu yaparken internet performansından ödün vermemek.

Bu yazıda, basit bir "reklam engelleyici kur geç" rehberinin ötesine geçeceğiz. Terminali açıp, sistemin derinliklerine inerek şunları nasıl yaptığımı anlatacağım:

Google veya Cloudflare'a güvenmek yerine, kendi Recursive DNS (Unbound) sunucumu yapılandırarak aracıları nasıl ortadan kaldırdım?
İnatçı ISS modeminin elinden DHCP yetkisini alarak ağ yönetimini nasıl tamamen kendi kontrolüme geçirdim?
Ve en önemlisi: CGNAT arkasında olmama rağmen, bu güvenli kaleye Tailscale ile dünyanın her yerinden nasıl şifreli bir tünel açtım?

Eski bir donanımı, modern bir güvenlik cihazına (Network Appliance) dönüştürme hikayesi başlıyor.

Araç Çantası (The Stack)

Bu projeyi hayata geçirmek için bir süper bilgisayara veya pahalı firewall cihazlarına ihtiyacınız yok. DNS sorguları ve VPN tünelleme işlemleri şaşırtıcı derecede hafiftir; bu yüzden "atıl donanım" felsefesi burada mükemmel işler.

1. Donanım (Elimdeki Envanter)

Bu proje için özel bir alışveriş yapmadım. Tamamen "çekmeceden ne çıkarsa" prensibiyle ilerledim.

Kart: Raspberry Pi 3 Model B
Neden Bu? Çünkü elimde boşta duran kart buydu. Ancak şansıma, dahili Ethernet portuna sahip olması DNS sunucusu için büyük avantaj. Wi-Fi gecikmesini (latency) veya sinyal kopmalarını bir DNS sunucusunda asla istemezsiniz. Kablo kararlılıktır.
Depolama: MicroSD Kart (Class 10)

Alternatifler

Elinizde illaki Raspberry Pi 3 gibi bit kart olmak zorunda değil. İşte diğer güzel alternatifler:

Raspberry Pi Zero W / 2W: Çok daha ucuz ve az güç tüketir. (Ancak Micro-USB Ethernet adaptörü kullanmanızı şiddetle öneririm).
Eski Bir Laptop: Ekranı kırık, bataryası bitik eski dizüstü bilgisayarınız harika bir sunucu olur. Üstelik dahili bataryası "UPS" (Kesintisiz Güç Kaynağı) görevi görür.
Orange Pi / Banana Pi: Piyasadaki Raspberry Pi klonlarının çoğu bu proje için fazlasıyla yeterlidir.
Always-Free Cloud VPS: Oracle Cloud veya Google Cloud'un ücretsiz katmanlarında (Free Tier) bir Ubuntu sunucu açıp, ev ağınıza Tailscale "Subnet Router" olarak bağlayabilirsiniz. (Donanım maliyeti: 0₺).

2. Yazılım (Software)

Burada "bloat"tan (gereksiz şişkinlikten) kaçınan, Unix felsefesine uygun (bir şeyi yap ve iyi yap) araçları seçtim:

İşletim Sistemi: Raspberry Pi OS Lite (64-bit).
Masaüstü ortamı (GUI) yok, sadece terminal. Bir sunucunun monitöre ihtiyacı yoktur. Headless kurulum yapacağız.
Pi-hole: Ağ seviyesinde reklam ve takipçi engelleyici (DNS Sinkhole).
Unbound: Recursive DNS çözümleyici. Google'a veya diğer DNS sağlayıcılarına güvenmek yerine kendi doğrulamamızı yapacağız.
Tailscale: WireGuard tabanlı Mesh VPN. CGNAT duvarlarını delmek ve dışarıdan eve güvenli tünel açmak için.

🏗️ Bölüm 1: Temeli Atmak (İşletim Sistemi Kurulumu)

Bir sunucu kuruyorsak, ilk kural şudur: GUI (Grafik Arayüz) gereksiz yük ve güvenlik açığıdır. Sunucunun monitörü olmaz, terminali olur. Bu yüzden "Raspberry Pi OS Lite (64-bit)" sürümünü tercih ettim.

Adım 1: İmajı Yazdırmak

Raspberry Pi kullandığım için işim nispeten kolaydı. Resmi Raspberry Pi Imager yazılımı, sadece imajı karta yazmakla kalmıyor, "OS Customization" özelliğiyle SSH ayarlarını daha kartı cihaza takmadan yapmamızı sağlıyor.

Cihaz Seçimi: Raspberry Pi 3.
İşletim Sistemi: Raspberry Pi OS (Other) -> Raspberry Pi OS Lite (64-bit).
Neden 64-bit? Pi 3, 64-bit mimariyi destekler. MongoDB gibi bazı modern veritabanı ve servisler artık 32-bit desteğini kesiyor. Geleceğe yatırım yapmak iyidir.

3. Kritik Adım: "Headless" Hazırlık (OS Customization)

Bir sunucu kurarken monitör, klavye ve fare aramakla vakit kaybetmek istemeyiz. Amacımız "Tak ve Çalıştır" (Plug and Play) değil, "Tak ve Yönet" olmalı.

Raspberry Pi Imager'ın yeni sürümleri, "OS Customization" özelliği sayesinde işletim sistemini daha karta yazmadan konfigüre etmemize olanak tanıyor. Bu sayede Pi ilk açıldığı anda ağa bağlanıyor, SSH kapısını açıyor ve bizim bağlanmamızı bekliyor.

İmajı yazdır ("Write") demeden önce, o sihirli ayar menüsünü açarak şu konfigürasyonları yaptım:

Hostname (Cihaz Adı): Cihaza ağda tanınacağı kimliği verdim: pi-hole. (Siz dns-server veya yaratıcı başka bir isim seçebilirsiniz).
Enable SSH (SSH'ı Aç): Bu adım hayati önem taşıyor. Cihaza monitör bağlamayacağımız için tek iletişim yolumuz bu olacak. "Use password authentication" seçeneğini aktif ettim.
Username & Password: Buraya kendime özel, kullanıcı adı ve güçlü bir şifre tanımladım.
Wireless LAN (Wi-Fi): Burayı bilinçli olarak boş bıraktım. Bir DNS sunucusu kablosuz ağın kararsızlığına emanet edilemez. Ethernet kablosu takılı olacağı için Wi-Fi konfigürasyonuna ihtiyacımız yok.

Bu ayarları kaydedip "WRITE" butonuna bastığımda, elimde sadece bir işletim sistemi değil, tamamen benim kurallarımla yapılandırılmış, göreve hazır bir sunucu kartı vardı.

Laptop veya Mini PC Kullananlar İçin Not

Eğer bu projeyi eski bir laptop veya Intel NUC gibi bir x86 cihazda yapacaksanız süreç biraz daha geleneksel:

Hafif bir dağıtımın ISO dosyasını indirin (Örn: Debian Server veya Ubuntu Server).
Rufus veya BalenaEtcher kullanarak USB belleğe yazdırın.
Cihazı USB'den başlatıp kurulumu tamamlayın.

Adım 2: İlk Önyükleme (First Boot) ve Ağ Taraması

SD kartı Pi'ye taktım, Ethernet kablosunu modeme bağladım ve gücü verdim. Işıklar yanıp sönmeye başladı ama kritik bir eksiğimiz var: Monitörsüz bir cihazın IP adresini nasıl bulacağız?

Bunun için iki yolumuz var.

Yöntem 1: Klasik Yol (Modem Arayüzü)
En garantili yöntem, ağın patronuna yani modeme sormaktır. 192.168.1.1 (veya modeminizin IP'si neyse) adresinden arayüze giriş yapıp "Bağlı Cihazlar" (Connected Devices) listesine baktığınızda, Raspberry Pi'nin sessizce bir IP aldığını göreceksiniz.

Yöntem 2: Terminal Yolu (Nmap Taraması)
Eğer modem şifresini hatırlamıyorsanız veya tarayıcıyla uğraşmak istemiyorsanız, terminalden ağı taramak çok daha hızlı bir yöntemdir.

Ağdaki cihazları ve üreticilerini listelemek için şu komutu kullandım:

# -sn: Port taraması yapma, sadece ping at (Ping Scan)
sudo nmap -sn 192.168.1.0/24

Ve işte aradığım cevap karşımda:

Nmap scan report for PC192.168.1.4.station (192.168.1.4)
Host is up (0.0040s latency).
MAC Address: B8:27:EB:4B:79:A8 (Raspberry Pi Foundation)

Terminal, üreticisi "Raspberry Pi Foundation" olan cihazın 192.168.1.4 adresinde olduğunu raporladı.

Bağlantı Anı

Hedef belli olduğuna göre, o büyülü an geldi. SSH ile sisteme giriş yapıyoruz:

ssh hakan@192.168.1.4

İçerideyim. 🎉

Ancak titiz bir Linux kullanıcısı olarak, ilk iş htop ve systemd-analyze komutlarını çalıştırdığımda gördüğüm manzara beni tatmin etmedi. Kullanmadığım donanımlar için çalışan servisler ve arka plandaki gereksiz yükler (bloatware), açılış süresini uzatıyordu.

hakan@pi-hole:~ $ systemd-analyze
Startup finished in 5.988s (kernel) + 52.832s (userspace) = 58.821s 
multi-user.target reached after 22.577s in userspace.

Sıradaki adımda, elime dijital süpürgeyi alıp bu sistemi temizlemem ve sunucu kondisyonuna getirmem gerekiyordu.

🧹 Bölüm 2: "Lite" Yeterince Hafif Değildir (System Hardening)

Sisteme ilk bağlandığımda htop ve systemd-analyze blame komutlarını çalıştırdım. Gördüğüm manzara, bir sistem mühendisi için kabul edilemezdi. Boot süresi 1 dakikaya yakındı ve kullanmadığım donanımlar için servisler çalışıyordu.

Raspberry Pi OS Lite, genel uyumluluk için "herkese her şey" mantığıyla gelir. Ancak bizim senaryomuzda Headless (Monitörsüz) ve Kablolu (Ethernet) bir DNS sunucusu kuruyoruz. Fazlalıklara yer yok.

İşte uyguladığım "diyet" programı:

1. Baş Şüpheli: Cloud-Init

En büyük gecikmeyi (yaklaşık 50 saniye) cloud-init servisi yaratıyordu. Bu servis, cihaz bir bulut ortamında (AWS, Azure vb.) çalışıyorsa metadata çekmeye yarar. Benim Pi'm masamın üstündeydi, bulutta değil.

# Servisleri durdur
sudo systemctl disable --now cloud-init-local.service cloud-config.service cloud-final.service

# Paketi ve kalıntılarını sistemden kazı
sudo apt purge -y cloud-init
sudo rm -rf /etc/cloud /var/lib/cloud

2. Gereksiz Donanım Servisleri

Sunucumda hoparlör, bluetooth kulaklık veya Wi-Fi kullanmayacağım. Bunları kapatmak hem RAM kazandırır hem de saldırı yüzeyini (attack surface) daraltır.

# Bluetooth ve Ses (ALSA) servislerini kaldır
sudo apt purge -y bluez bluez-firmware alsa-utils

# ModemManager (3G/4G dongle kullanmayacaksanız gereksiz)
sudo apt purge -y modemmanager

# Wi-Fi Servisi (Ethernet kullandığım için)
sudo systemctl disable --now wpa_supplicant
sudo systemctl mask wpa_supplicant

3. Avahi (mDNS)

Sabit IP kullanacağım ve DNS yönetimini kendim yapacağım için raspberrypi.local gibi mDNS yayınlarına (Bonjour) ihtiyacım yoktu.

sudo systemctl disable --now avahi-daemon
sudo apt purge -y avahi-daemon

4. Son Temizlik, Güncellemeler ve Yeniden Başlatma

Sistemi gereksiz servislerden arındırdık. Sistemde yaptığım cloud-init ve diğer temizliklerden sonra geriye, artık hiçbir işe yaramayan "yetim" paketler (orphan packages) kalmıştı. Terminal bana bunları temizlememi öneriyordu, ben de öneriye uydum:

sudo apt autoremove -y

Artık elimizde, üzerine bina inşa edebileceğimiz tertemiz bir temel var. Bu temeli en son güncellemeler ile güçlendirelim:

sudo apt update && sudo apt upgrade -y

Sistemi yeniden başlatıp sonuca bakalım:

sudo reboot now

Yeni sonuçlar ise daha tatmin edici:

hakan@pi-hole:~ $ systemd-analyze
Startup finished in 9.046s (kernel) + 21.894s (userspace) = 30.941s 
multi-user.target reached after 20.891s in userspace.

⚓ Sabit IP (Static IP) Ayarı

Temizlik bitince, ağdaki yerimizi sağlamlaştırmamız gerekiyordu. DNS sunucusunun IP adresi değişirse tüm evin interneti kesilir.

Modern Raspberry Pi OS sürümleri NetworkManager kullanır. IP sabitlemek için en temiz yol nmtui aracıdır.

Terminale sudo nmtui yazdım.
Edit a connection -> netplan-eth0.
IPv4 CONFIGURATION -> Manual.
Addresses: 192.168.1.4/24 (Siz kendi ağınıza göre belirleyin).
Gateway: 192.168.1.1 (Modem IP'si).
DNS Servers: Şimdilik 1.1.1.1 (Kurulum bitince 127.0.0.1 yapacağız).
(Opsiyonel) IPv6 CONFIGURATION -> Disabled (Eğer IPv6 kullanmıyorsanız yapabilirsiniz).

Sistemi yeniden başlatabiliriz:

sudo reboot now

🛡️ Bölüm 3: Savunma Hattı (Pi-hole & Unbound)

Temiz bir işletim sistemimiz var. Şimdi onu bir ağ cihazına (Network Appliance) dönüştüreceğiz. Buradaki stratejimiz iki katmanlı:

Pi-hole: Reklamları ve izleyicileri çöpe atan bekçi.
Unbound: Sorguları Google'a sormak yerine, doğrudan internetin kök sunucularından (Root Servers) öğrenen çözümleyici.

Adım 1: Pi-hole Kurulumu (Bekçi)

Pi-hole kurulumu, Linux dünyasının en pratik scriptlerinden birine sahip. Terminale şu komutu yapıştırarak kurulum sihirbazı başlattım:

sudo curl -sSL https://install.pi-hole.net | bash

Sihirbaz sırasında dikkat ettiğim kritik noktalar:

Static IP: Burada size basit bir uyarı veriyor. Cihazın IP'sinin statik olması gerektiğini özellikle belirtiyor. Biz bunu önceki adımda tamamladık.
Upstream DNS: Kurulum sırasında herhangi birini (örn: Google) seçebilirsiniz, birazdan bunu değiştireceğiz.
Bloclist: Burada pihole un kullandığı 3. pari filtreler için bildirge var. Ben kullanmak istediğim için 'yes'i seçtim.
Query Logging: Eğer aşırı gizlilik isterneniz 'no' yu seçebilirsiniz. Ben 'yes' ile devam ettim.
Privacy mode for FTL: Kullanıcıların hangi siteye sorgu gönderdiğini web arayüzünde göstermek için Show Everything ile devam ettim.

Adım 2: Erişim ve Yetkilendirme (Post-Install)

Kurulum sihirbazı bitti ama terminalden henüz çıkmıyoruz. Özellikle Pi-hole v6 mimarisiyle gelen önemli bir değişikliği yapılandırmamız gerekiyor.

CLI için API Yetkilendirmesi
Pi-hole v6, CLI (Komut Satırı) komutları için artık doğrudan veritabanı manipülasyonu yerine yeni API'sini kullanıyor. Bu güvenlik açısından harika olsa da, her komut girdiğimizde bizden parola istemesi (API authentication) can sıkıcı olabilir.

Bir sistemci "sudo" yazmaya alışkındır ama gereksiz parola girmekten nefret eder. Kendi kullanıcımızı pihole grubuna ekleyerek, terminalden parola girmeden yönetim komutlarını çalıştırabilme yetkisi verelim:

# Mevcut kullanıcımızı ($USER), pihole grubuna ekle
sudo usermod -aG pihole $USER

Not: Bu değişikliğin aktif olması için SSH oturumunu kapatıp (exit) tekrar bağlanmanız gerekebilir.

Web Arayüzü Şifresi
Pi-hole kurulum sırasında rastgele bir şifre atar. Web arayüzüne (http://192.168.1.4/admin) her girişte loglara bakmak için o karmaşık şifreyi aramak istemeyiz.

Aklımızda kalacak güçlü bir şifre belirleyelim:

pihole setpassword

Komutu girdikten sonra yeni şifrenizi yazın (ekranda görünmeyecektir) ve onaylayın.

Artık hem terminalde hem de web arayüzünde tam yetkiliyiz. Sıra geldi DNS sorgularını özgürleştirmeye: Unbound Kurulumu.

Adım 3: Unbound Kurulumu (Özgürlük)

İşte işin mühendislik kısmı burada başlıyor. Çoğu kullanıcı Pi-hole'u kurar ve DNS olarak Google (8.8.8.8) kullanmaya devam eder. Bu, reklamları engeller ama gizliliğinizi korumaz. Verileriniz hala Google'a akar.

Biz Recursive DNS kuracağız. Yani aracıları aradan çıkaracağız.

sudo apt install unbound -y

Adım 3: Konfigürasyon ve Hız Optimizasyonu 🚀

Unbound'un varsayılan ayarları güvenlik odaklıdır ancak biraz hantaldır. Benim buradaki amacım ise gecikme hissini biraz da olsa azaltmak.

Bunun için Unbound konfigürasyon dosyasını oluşturdum:

sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

Ve içine şu optimize edilmiş ayarları girdim. (Buradaki serve-expired parametresi sihirli dokunuştur):

server:
    # Log seviyesi (Hata ayıklama gerekmedikçe 0)
    verbosity: 0
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # IPv6'yı kapat (Ev ağında gecikme yaratabilir)
    do-ip6: no

    # Root Hints dosyası
    root-hints: "/var/lib/unbound/root.hints"

    # Gizlilik Ayarları
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes

    # --- PERFORMANS OPTİMİZASYONLARI ---

    # Süresi bitmiş kayıtları (expired) anında sun, arkada güncelle
    serve-expired: yes
    serve-expired-ttl: 86400  # 1 gün

    # Cache boyutlarını Pi 3'ün RAM'ine göre ayarla
    msg-cache-size: 50m
    rrset-cache-size: 100m

    # İşlemci çekirdeklerini kullan
    num-threads: 2

Dosyayı kaydettikten sonra kök sunucuları resmi kaynaktan (InterNIC) en güncel Root Hints listesini çekip Unbound'un beklediği klasöre koyalım ve izinlerini sağlama alalım:

# Dosyayı indir
sudo wget -O /var/lib/unbound/root.hints https://www.internic.net/domain/named.root

# İzinleri ayarla (Unbound kullanıcısının okuyabildiğinden emin olalım)
sudo chown unbound:unbound /var/lib/unbound/root.hints

Dosyayı kaydedip (CTRL+X, Y, Enter) Servisi yeniden başlatalım:

sudo systemctl restart unbound

Ayrıca unbound servisi her açılışta otomatik açılacak şekilde ayarlayalım:

sudo systemctl enable unbound

Adım 4: Büyük Buluşma (Entegrasyon)

Artık Pi-hole'a "Google ile konuşma, yan odadaki Unbound ile konuş" dememiz lazım.

Sabit IP (Static IP) Ayarı Yaptığımızda DNS Servers kısmına 1.1.1.1 vererek DNS sunucusunu cloudflare olarak ayarlamıştık. Şimdi o ayarı değiştirerek 127.0.0.1 yapıp dns sunucusunu yerel cihaz olarak değiştirdim.
Web tarayıcısından http://192.168.1.4/admin adresine girdim.
Settings > DNS sekmesine geldim.
Sağdaki hazır listelerin (Google, OpenDNS vb.) hepsinin tikini kaldırdım.
Custom 1 (IPv4) kutusuna şunu yazdım: 127.0.0.1#5335.

Sonuç:
Şu anda ağımda bir reklam engelleme servisi çalışıyor ve DNS sorgularım şifreli, doğrulanmış ve aracı olmadan çözülüyor. Ancak bir sorun var: Cihazlarım (Telefon, TV) hala modemi dinliyor.

Sıradaki adımda "Ağ Yönetimini Ele Geçirme" (DHCP Handover) operasyonunu yapacağız.

⚔️ Bölüm 4: Modemi "Aptallaştırmak" (DHCP Operasyonu)

Pi-hole ve Unbound hazırdı. Normal şartlarda, modem arayüzüne girip DNS adresini 192.168.1.4 olarak değiştirmek yeterli olmalıydı.

Ancak teori ve pratik, ISS modemlerinde asla uyuşmaz.

Kullandığım modem (Vodafone H300s), çoğu ISS cihazı gibi "kilitli" bir kutuydu. DNS ayarlarını değiştirmeme izin verse bile, arka planda ikincil DNS olarak kendi sunucularını zorluyor veya bazı cihazlar (özellikle Android TV ve Chromecast) inatla modemin önerdiği DNS'e gidiyordu. Sonuç? Reklamlar sızmaya devam ediyordu.

"Kibarca" rica ettim olmadı. Ben de yönetimi zorla almaya karar verdim.

Çözüm: Modemin DHCP sunucusunu kapatmak ve IP dağıtma yetkisini Pi-hole'a vermek.

Bu yöntem iki devasa avantaj sağlar:

Garanti Yönlendirme: Pi-hole, IP dağıtırken cihazlara "Tek DNS benim, başka yere bakma" der. Kaçış yoktur.
Detaylı Analiz: Modem DHCP iken Pi-hole loglarında tüm trafiği tek bir cihazdan (Modem) geliyormuş gibi görürsünüz. Pi-hole DHCP olduğunda, hangi cihazın (iPad, TV, Laptop) hangi siteye girdiğini tek tek görebilirsiniz.

Operasyon Sırası (Dikkat!)

Ağdan kopmamak için sıralama hayati önem taşır. Önce yeni patronu (Pi-hole) devreye almalı, sonra eskisini (Modem) emekli etmelisiniz.

Adım 1: Yeni Patronu Hazırla (Pi-hole)

Pi-hole panelinde Settings > DHCP sekmesine gittim.
DHCP server enabled kutusunu işaretledim.
Range: Modeminkiyle çakışmayacak bir aralık verdim (Örn: 192.168.1.5 - 192.168.1.254).
Router (Gateway): Modemin IP adresini (192.168.1.1) girdim. Burası çok kritik, yanlış girerseniz internete çıkamazsınız.

Adım 2: Eskisini Sustur (Modem)

Modem arayüzüne girdim.
LAN / Yerel Ağ ayarlarından DHCP Sunucusu seçeneğini KAPALI (Disable) konuma getirdim.
Kaydettim.

Adım 3: Sözleşme Yenileme (Renew Leases)

Şu an ağda bir kaos yok ama cihazların hala eski "kira sözleşmeleri" (IP Lease) var. Onları yenilemek için:

Telefonun Wi-Fi özelliğini kapatıp açtım.
Bilgisayarın Ethernet kablosunu çıkarıp taktım.

Sonuç: Pi-hole panelindeki "DHCP Leases" kısmında cihazlarımın tek tek belirdiğini gördüm. Artık ağın mutlak hakimi Raspberry Pi idi. Modem ise sadece internet sinyalini içeri taşıyan "aptal" bir kutuya (Dumb Pipe) dönüşmüştü. Tam istediğim gibi.

🌍 Bölüm 5: Duvarların İçinden Tünel Açmak (CGNAT ve Tailscale)

Ev ağım artık bir kaleydi: Reklamlar giremiyor, DNS sorguları dışarı sızmıyordu. Ancak büyük bir sorunum vardı: Ben de eve giremiyordum.

Evden çıktığım anda (mobil veri veya kafe Wi-Fi'ı), ISS'mın güvenli olmayan ağına veya halka açık güvensiz ağlara mahkum kalıyordum. Eve bağlanmak için geleneksel yöntem, modemden port açmaktır. Ancak Türkiye'deki çoğu ev kullanıcısı gibi ben de CGNAT (Carrier Grade NAT) havuzundayım. Yani gerçek bir genel (public) IP adresim yok, bir apartman bloğu gibi binlerce kişiyle aynı IP'yi paylaşıyorum. Dolayısıyla dışarıdan içeriye kapı (port) açmam teknik olarak imkansız.

Çözüm? NAT Traversal (NAT Aşımı) ve Overlay Network.

Burada Tailscale devreye giriyor. Tailscale, ISS'nın karmaşık NAT duvarlarını yıkmaz (bunu yapamayız), ancak "NAT Traversal" tekniklerini kullanarak bu duvarların içinden şifreli bir tünel (WireGuard) açar.

Bu sayede ISS altyapısını kullanmaya devam ederiz ancak ISS, paketlerimizin içeriğini veya nereye gittiğini (DNS) göremez. Sadece şifreli bir veri akışı görür. Kısacası ISS'yı, veriyi sadece A noktasından B noktasına taşıyan "kör" bir taşıyıcıya (Dumb Pipe) dönüştürürüz.

Adım 1: Kurulum ve IP Yönlendirme

Headless sunucuma tek satırla Tailscale'i kurdum:

curl -fsSL https://tailscale.com/install.sh | sh

Tailscale bir "Overlay Network" (Katman Ağı) oluşturur. Ancak Linux çekirdeği varsayılan olarak üzerinden geçen trafiği (packet forwarding) engeller. Pi'nin gelen trafiği internete taşıması için çekirdek ayarlarını değiştirdim:

# IPv4 Forwarding'i aç
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
# Eğer IPv6 Kullanacaksanız:
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Adım 2: Sihirli Komut (Exit Node)

Servisi başlatırken Pi'ye "Sen artık bu sanal ağın internete çıkış kapısısın" dedim:

sudo tailscale up --advertise-exit-node

Bana verdiği linke tıklayıp cihazı hesabımla eşleştirdim.

Adım 3: Admin Onayı (Güvenlik)

Bu adım genellikle unutulur. Terminalden "ben çıkış kapısıyım" demek yetmez, Tailscale yönetim panelinden (Web) buna izin vermeniz gerekir.

Admin Paneli > Machines > pi-hole > Edit Route Settings.
Use as exit node seçeneğini aktif ettim.

Adım 4 (Opsiyonel ama Önemli): Anahtar Süresini Uzatmak (Disable Key Expiry)

Tailscale, güvenlik tedbiri olarak cihazların oturum anahtarlarını belirli aralıklarla (varsayılan 180 gün) geçersiz kılar. 7/24 çalışan bir sunucu için bu risklidir; tam ihtiyacınız olduğu anda erişiminiz kesilebilir.

Bu "baş ağrısını" yaşamamak için Pi-hole sunucumuzun oturum süresini kalıcı hale getiriyoruz:

Admin Paneli > Machines listesinden pi-hole cihazını bulun.
Sağdaki üç noktaya tıklayıp Disable Key Expiry seçeneğini işaretledik.

🎉 Sonuç: Dijital Özgürlük

Telefonumun Wi-Fi'ını kapattım, mobil veriye geçtim. Tailscale uygulamasından "Exit Node" olarak evdeki Pi'mi seçtim ve testi başlattım:

Tünel Testi (Exit Node): whatismyip.com'a girdiğimde, mobil operatörümün IP'sini değil, evimdeki fiber hattın IP'sini gördüm. Trafiğim şifreli bir tünelden eve gidiyor, oradan internete çıkıyordu.
Sanal Yerel Ağ: Tarayıcıya Pi-hole'un Tailscale IP adresini (100.x.x.x) yazdığımda, sanki evde masamda oturuyormuşum gibi yönetim paneli karşımdaydı. CGNAT engelini, sanal bir ağ katmanıyla aşmıştım.
Termux ile Tam Kontrol: Mobil telefonumdan Termux'u açıp, yine aynı Tailscale IP'sine SSH bağlantısı kurdum.

Özetle:
ISS'yi veya CGNAT'ı yok etmedik; bu fiziksel olarak imkansızdı. Ancak kurduğumuz bu yapı ile onları sadece şifreli paket taşıyan bir altyapıya indirgedik.

DNS sorgularımızı göremiyorlar (Unbound + Şifreleme).
Hangi sitelere girdiğimizi analiz edemiyorlar (VPN Tüneli).
Bize "public IP vermiyoruz, eve bağlanamazsın" diyemiyorlar (Tailscale/NAT Traversal).

Eski bir Raspberry Pi ve doğru mühendislik yaklaşımıyla; binlerce liralık kurumsal cihazların sunduğu "Zero Trust" konforunu evimize getirdik.

Çekmecenizdeki o kartı çıkarın. İnternetiniz size ait olsun.