Merhaba, bu yazımda Failover Cluster spesifik ayarlar ve optimizasyonlar şeklinde bölüm 3 şeklinde devam ediyorum.
NIC Teaming ve Ağ Adaptörü Yapılandırmaları
Cluster düğümlerindeki ağ adaptörlerinin düzgün yapılandırılması, kesintisiz iletişim ve yüksek erişilebilirlik için kritik önem taşır. NIC Teaming, birden fazla fiziksel NIC’i tek bir mantıksal arayüzde birleştirerek hem bant genişliği artışı hem de yedeklilik sağlar. Windows Server’da yerleşik NIC Teaming özelliği mevcuttur ve “Switch Independent” (anahtardan bağımsız) veya “LACP/Static” modlarında takım oluşturulabilir.
NIC Teaming Ne Zaman Kullanılmalı?
Eğer cluster düğümünüzün istemci trafiği çok yoğunsa veya yalnızca tek bir fiziksel NIC’i varsa, NIC Teaming ile iki NIC’i birleştirip yük dengeleme ve yedeklilik elde edebilirsiniz. Örneğin 2x1Gb NIC teaming yaparak ~2 Gbps’ye yakın bir toplu bant genişliği ve bir NIC arızasında kesintisizliği sağlarsınız. Microsoft’un cluster dokümanlarında da vurguladığı üzere, ağ altyapınızda tek hata noktasını kaldırmak için NIC Teaming iyi bir yöntemdir.
Teaming yaparken, tüm cluster düğümlerinde benzer yapı uygulanmalıdır (örneğin her düğümde “Team1” adıyla iki NIC birleştirilmeli ve aynı amaçla kullanılmalı). Switch Independent modu, takımın çalışması için switch tarafında özel bir konfigürasyon gerektirmez ve genelde güvenlidir. LACP (Switch Dependent) modu ise switch ile koordineli çalışır ve genelde daha verimli dağıtım yapabilir ancak switch üzerinde LAG/LACP ayarı yapmanız şarttır.
Cluster Ağları ve Teaming
Cluster, takım arayüzünü tek bir NIC gibi göreceği için, eğer mümkünse her bir takımın içinde de en az iki fiziksel bağlantı olduğundan emin olun ki takım arızası çok düşük ihtimal olsun. Bazı yöneticiler, cluster heartbeat için doğrudan ayrılmış iki NIC kullanıp, bunları takım yapmadan ayrı iki cluster ağı tanımlamayı tercih eder (böylece cluster iki farklı yoldan iletişim kurar ve cluster yazılımı her iki yolun durumunu ayrı ayrı izler).
Bu da geçerli bir yaklaşımdır. Alternatif olarak, heartbeat için ayrılan iki NIC’i bir takım yaparak cluster’a tek bir yol gibi sunabilirsiniz – bu durumda cluster, takımın altındaki fiziksel sorunları bilemez ama takım mekanizması kendi içinde yedekliliği halleder. İki yöntem de uygulanabilir; önemli olan, tek NIC’e bağımlı kalınmamasıdır. Eğer NIC Teaming kullanıyorsanız, cluster validation testlerinde ağ için “teamed adapter” uyarıları çıkabilir, bu normaldir ancak iletişimi doğrulayın.
Ağ Aygıtı İyileştirmeleri
Her bir NIC’in en güncel sürücüsünün yüklü olması ve hız/duplex değerlerinin doğru şekilde (genelde auto-negotiate ile 1 Gbps Full Duplex veya 10 Gbps Full) çalıştığının doğrulanması gerekir. Farklı hızdaki NIC’leri aynı team’e koymaktan kaçının (örneğin bir 1Gbps ile bir 10Gbps’yi aynı takımda kullanmak verimsizdir).
iSCSI NIC’lerinde TOE, RSS gibi offload özellikleri faydalı olabilir, fakat cluster iletişim NIC’lerinde bazen bu özellikler beklenmedik sorunlara yol açabilir – herhangi bir kararsızlık durumunda bu gelişmiş özellikleri devre dışı bırakıp test etmek gerekebilir.
VLAN ve Network Partitioning
Cluster düğümlerindeki NIC’ler eğer birden fazla VLAN’ı trunk olarak taşıyorsa, yönetimsel olarak sanal NIC’ler oluşturup cluster’ın her VLAN için ayrı sanal adaptör görmesi sağlanabilir. Örneğin tek 10Gbps fiziksel NIC’iniz var ama hem depolama hem heartbeat hem istemci trafiği için farklı VLAN’lar kullanacaksanız, Hyper-V sanal switch veya SDN yapısıyla sanal NIC’ler (vNIC) tanımlanabilir. Bu durumda da cluster her vNIC’i ayrı ağ olarak görecektir. Bu mimari daha çok hyper-converged ortamlarda (Azure Stack HCI vs.) karşımıza çıkar, standart cluster için genellikle fiziksel NIC’ler ayrılarak yapılır.
Özetle: NIC Teaming sayesinde ağ kartı arızalarına karşı koruma sağlayabilir ve throughput’u artırabilirsiniz. Cluster içi kritik iletişim için birden fazla NIC veya team kullanarak tek noktadan arızayı önleyin. iSCSI gibi özel amaçlı NIC’lerde team yerine MPIO kullanmak daha uygun olabilir (çünkü iSCSI protokolü düzeyinde daha iyi yönetilir). Team’lerin sağlığını ve performansını Windows Performance Monitor veya Get-NetLbfoTeam PowerShell cmdlet’i ile izlemeyi unutmayın.
Cluster-Aware Updating (CAU) ile Sorunsuz Güncelleme
Windows Server Failover Cluster’larının en faydalı özelliklerinden biri de Cluster-Aware Updating (CAU) teknolojisidir. CAU, cluster düğümlerine işletim sistemi güncellemelerini (Windows Update, sürücü güncellemeleri vs.) uygulama sürecini otomatikleştirir *ve bunu yaparken hizmet sürekliliğini korur. Geleneksel olarak, birden fazla sunucudan oluşan bir cluster’ı güncellemek zahmetli olabilir: Her sunucuyu tek tek bakım moduna alıp güncelleyip yeniden başlatmak gerekir. CAU ise bu süreci otomatik bir “Güncelleme Çalışması (Updating Run)” olarak gerçekleştirir:
- CAU, cluster’daki her düğümü teker teker bakım moduna alır (Cluster’da “Pause/Drain Roles” işlemi.
- Bakım moduna alınan düğümdeki tüm cluster rolleri diğer düğümlere aktarılır (planned failover veya live migration ile.
- İlgili düğümde bekleyen Windows güncellemeleri (ve varsa bağımlı güncellemeler) *yüklenir.
- Gerekirse sunucu *yeniden başlatılır.
- Düğüm tekrar çevrimiçi olunca cluster’a tam katılımı sağlanır ve üzerindeki roller geri taşınır (veya uygun dengelemeyle cluster içinde kalır.
- CAU sonra sıradaki düğüme geçerek aynı işlemleri tekrarlar.
Bu süreç boyunca cluster hizmetleri tamamen durmaz; sadece her adımda tek bir düğüm geçici olarak ayrılır. Özellikle Hyper-V (Live Migration destekli) veya Sürekli Erişilebilir Dosya Sunucusu (SMB Transparent Failover özellikli) gibi roller kullanılıyorsa, sıfıra yakın kesinti ile güncellemeler uygulanabilir. Örneğin Hyper-V cluster’da CAU, VM’leri canlı olarak diğer düğüme taşıyıp host’u reboot eder, dolayısıyla VM’ler kesinti yaşamaz veya sürekli erişilebilir bir dosya sunucusunda, handle’lar diğer düğüme aktarılıp istemci bağlantıları kopmadan devam edebilir.
CAU kullanımı için cluster düğümlerinde uzaktan yönetim yeteneklerinin açık olması (WinRM vb.) ve düğümlerin birbirine güvendiği bir AD ortamında bulunması gerekir. CAU’yu Failover Cluster Manager üzerinden veya ayrı bir GUI aracıyla zamanlayabilirsiniz. Örneğin, CAU self-updating mode ile belirli aralıklarla (aylık, haftalık) otomatik olarak cluster’ı güncelleyebilir. Bu sayede yöneticinin elle patch süreciyle uğraşmasına gerek kalmaz ve tüm düğümler düzenli olarak güncel kalır.
Not: CAU yapılandırmasını yaparken, güncellemelerin nereden alınacağını (WSUS veya Windows Update internet), hangi güncelleme kategorilerinin uygulanacağını ve her bir düğüm için zaman aşımı/tolerans değerlerini belirleyebilirsiniz. CAU, cluster’daki kritik uygulamaların durumunu da izler; eğer bir güncelleme sonrası uygulama başlamazsa, işlemi duraklatabilir. Yine de CAU’yu tamamen sorunsuz çalışır hale getirmek için ilk kurulumda test etmek faydalıdır (örneğin bir düğümde başlatıp izle, logları kontrol et). CAU ayrıca Cluster Aware Updating PowerShell modülü ile komut satırından da yönetilebilir (ör. Invoke-CauRun cmdleti).
Dinamik Quorum ve Dinamik Tanık Ayarları
Failover cluster’larda Dinamik Quorum özelliği, Windows Server 2012 ile gelen ve cluster’ın mümkün olan en fazla sayıda arızaya direnebilmesini amaçlayan akıllı bir mekanizmadır. Dinamik quorum etkin olduğunda (varsayılan olarak etkindir), cluster her bir düğüme “oy” verip vermeme durumunu çalışma anında ayarlayabilir. Örneğin, 4 düğümlü bir cluster’da tüm düğümler ayaktayken 4 oy vardır ve çoğunluk 3’tür; eğer bir düğüm kaybedilirse cluster otomatik olarak toplam oy sayısını 3’e düşürüp çoğunluk eşiğini 2’ye ayarlar. Bu sayede bir düğüm gittiğinde kalanların hala çoğunluk sağlayabilmesi için şartlar adapte edilir. Sonraki bir düğüm de giderse, yine oy sayısı 2’ye düşürülüp çoğunluk 2’de tutulabilir, vs. Bu şekilde **ardışık kayıplar yaşandıkça cluster kendi çoğunluk hesabını “hayatta kalanlar” arasında yeniden tanımlar. Teorik olarak dinamik quorum, cluster’ın tek bir düğüm kalana dek (yani n-1 arıza) çalışabilmesini mümkün kılar – tabii ki bu son düğümde bir tanık yoksa tek başına çoğunluk sayılır. Dinamik quorum olmadan, oy hesapları sabit olduğundan belirli sayıda düğümden fazlası düşünce cluster kapanmak zorundaydı.
Windows Server’da dinamik quorum özelliği **otomatik olarak etkindir ve Microsoft bunu devre dışı bırakmamanızı önemle tavsiye eder. Failover Cluster Manager’daki Quorum ayar sihirbazında bu seçenek sunulur ancak default “Enabled” gelir. Dinamik quorum sayesinde cluster, “son düğüme kadar” ayakta kalmaya çalışacağından yüksek erişilebilirlik artar. Özellikle iki düğümlü cluster gibi kırılgan yapıların, dinamik tanık ile birlikte daha dayanıklı olması sağlanır.
Dinamik Tanık (Dynamic Witness)
Dinamik quorum ile birlikte gelen bir diğer özellik de dinamik tanıktır. Bu mekanizma, cluster’a eklenen bir tanık (disk veya dosya paylaşımı) kaynağının oyunun duruma göre açılıp kapanmasını ifade eder. Dinamik tanık, cluster’daki toplam oy sayısını tek tutmak için tanığın oy hakkını otomatik olarak devreye sokar veya çıkarır. Eğer düğüm oylarının toplamı tek ise tanığın oyu devre dışı bırakılır (0 oy sayılır); düğüm oylarının toplamı çift ise tanık **oylama hakkı kazanır. Böylece, tanık eklenmesiyle ortaya çıkabilecek “tanık da gitti cluster çöktü” riski azaltılır – tanık cluster’ı düşürecek bir yük durumuna gelmez.
Örneğin 3 düğüm + 1 tanıklı bir cluster’da dinamik tanık, 3 düğüm up iken tanığı oy dışı bırakır (3 oy zaten tek); eğer bir düğüm düşerse kalan 2 düğüm + tanık = 3 oy ile devam eder; bir düğüm daha düşerse 1 düğüm + tanık = 2 oy (çoğunluk 2’nin 2’si) ile teoride devam edebilir. Bu sayede cluster tanığı kaybetse bile (örneğin dosya paylaşımı sunucusu down oldu diyelim) ve o sıra düğümlerde eşit bölünme olsa dahi cluster bunu daha iyi yönetir. Dinamik tanık kuralı Windows Server 2012 R2 ve sonrası için geçerlidir ve default aktiftir. Bu ayar da Cluster Quorum Wizard’da “Automatically manage witness vote” gibi bir ibareyle görülür.
Yapılandırma
Genelde elle yapılacak bir şey yoktur çünkü dinamik quorum/witness otomatik gelir. Sadece bilinmesi gereken, bu özellikleri kapatmamak gerektiğidir. Özel senaryolarda (örneğin cluster davranışını detaylı kontrol etmek gereken nadir durumlarda) dinamik quorum devre dışı bırakılabilir ancak bu durumda cluster’ın arızalara toleransı ciddi oranda düşer.
Get-Cluster çıktısında DynamicQuorum ve DynamicWitness ayarları görülebilir; ikisi de “Enabled” olmalıdır. Değilse, (Set-Cluster).DynamicQuorum = 1 ve tanık için de uygun parametrelerle dinamikleştirilebilir. Özetle, cluster’ınızın quorum ayarlarında dinamik yönetimin etkin olduğundan emin olun – bu sayede clusterınız daha yüksek bir süreklilikle çalışacaktır.
Cluster Depolama Ayarları (CSV Kullanımı ve Storage Spaces Direct)
Cluster’ınızda paylaşımlı diskleri ekledikten sonra, bu disklerin nasıl kullanılacağına dair iki temel seçenek vardır: Klasik failover disk kaynakları veya Cluster Shared Volumes (CSV). Ayrıca eğer Storage Spaces Direct kullanıyorsanız, cluster depolama mimarisi zaten CSV üzerine kurulu olacaktır.
Cluster Shared Volumes (CSV): CSV, Windows Server 2008 R2 ile tanıtılan ve Windows Server 2012 ile olgunlaşan bir özelliktir. Bir CSV, cluster içindeki bir LUN’ın tüm düğümler tarafından eş zamanlı olarak okunup yazılabilmesini sağlar. Normalde bir paylaşımlı disk, aynı anda yalnızca bir düğümün sahipliğinde olur (Owner) ve sadece o düğüm tarafından kullanılabilir; başka bir düğüme failover olunca sahiplik değişir ve disk o düğümde mount edilir. CSV ise bu kısıtı ortadan kaldırır.
NTFS dosya sisteminin özel bir küme katmanı ile birden çok düğüm aynı diske aynı anda erişebilir. Bu, özellikle Hyper-V gibi her düğümün aynı depoyu kullanarak VM çalıştırdığı senaryolarda çok faydalıdır – tüm VM sanal disklerini tek bir büyük LUN’da tutup, VHDX dosyaları farklı düğümlerdeki Hyper-V’ler tarafından aynı anda erişilebilir olur (her VM tek bir hostta çalışsa da, diskleri ortak alanda olduğu için başka hosta taşındığında anında erişmeye devam eder). CSV, cluster içi bir mini dosya sistemi gibi çalışır.
Tüm CSV’ler, düğümlerde C:\ClusterStorage\VolumeX\ yoluna mount edilir ve bu yol tüm düğümlerde aynı görünür. Örneğin CSV Volume1 altında VM’lerinize bir dizin oluşturur ve VHD’leri oraya koyarsanız, hangi host aktif olursa olsun aynı yol geçerli olur, yeniden mount işlemi gerekmez.
CSV’nin avantajları
Hızlı Failover
Bir CSV kullanıldığında, bir rol diğer düğüme geçtiğinde disk yeniden mount edilmez, çünkü zaten her düğüm erişim sahibidir. Bu sayede failover süresi, diski bırak-al işlemi olmadığı için daha kısadır.
Basit Yönetim
Birçok küçük LUN yerine daha büyük ortak LUN’lar oluşturup hepsini CSV olarak bağlayabilirsiniz. Özellikle onlarca VM için ayrı ayrı LUN yönetmek yerine, birkaç büyük CSV’ye bölmek yönetimi kolaylaştır.
Erişim Tipleri
CSV, NTFS ya da ReFS ile formatlanmış olabilir. Ancak not: ReFS kullanımı belirli senaryolarda (Örneğin Scale-out File Server 2012 R2 ve önceki sürümlerde) desteklenmeyebilir. Genellikle CSV için NTFS önerilir (performans ve uyumluluk açısından. Windows Server 2016+ ile ReFS, Hyper-V için bazı avantajlar sağlasa da (hızlı birleştirme vb.), ReFS kullanımı CSV’de hala bazı kısıtlarla gelebilir. Bu detayı ortamınıza göre değerlendirin.
Uygulama Senaryoları
CSV’ler en çok Hyper-V ve Scale-Out File Server senaryolarında kullanılır. Ayrıca Windows Server 2014 ve üstü SQL Server Failover Cluster Instance kurulumlarında da CSV desteklenmiştir (daha eski SQL FCI sürümleri CSV desteklemezdi, şimdileri mümkün. Yine MSDTC gibi bazı hizmetler de Windows Server 2019 itibariyle CSV ile çalışabilir hale gelmiştir.
CSV kullanmak için, Failover Cluster Manager’da Depolama > Diskler altında listelenen bir paylaşımlı diske sağ tıklayıp “Add to Cluster Shared Volumes” demeniz yeterlidir. Disk CSV’ye eklendiğinde, otomatik olarak C:\ClusterStorage\ altına bir klasör olarak mount olur. Artık bu disk, “CSVFS” modunda tüm düğümlere açıktır.
CSV Koordinatörü
Her CSV’nin bir “coordinator” düğümü vardır (failover cluster bu rolü otomatik atar). Koordinatör, bazı bakım işlemlerini (örneğin disk o CSV’de CHKDSK gerekirse) üstlenen düğümdür. Normal IO trafiğinde her düğüm kendi üzerinden doğrudan diske yazar/okur.
Sadece düğümler arası senkronizasyon gereken durumlarda (örneğin metadata güncelleme, veya bir düğüm diske direkt erişemez hale gelirse) CSV, redirected mode denen moda geçip trafiği koordinatör üzerinden yönlendirebilir. Cluster Manager’da CSV’lerin durumunda “Redirected Access” ibaresi görürseniz, bir sorun olduğunun göstergesidir (ağ kesintisi veya depolama erişim sorunu gibi). Bu durumda olay günlüklerini kontrol etmek gerekir.
CSV En İyi Uygulamalar
Bir cluster’da CSV kullanırken, Microsoft birkaç tavsiyede bulunur:
- Bir cluster içindeki tüm CSV’ler ortak bir subnet üzerinden iletişim kurar. Yani CSV trafiği cluster internal network üzerinden akar. Bu nedenle heartbeat ağınız hızlı ise CSV koordinasyon mesajları da hızlı olur. CSV iletişimi için cluster otomatik en iyi ağı seçer.
- Antivirüs ve Yedekleme: CSV volumelerine erişen yazılımlar (antivirüs taraması, backup agent’ları) CSV destek modunda çalışmalıdır. Windows Server 2012 ile CSV, bu tür yazılımlar için geliştirmeler içerir . Örneğin Microsoft’un sistem durumu yedeği (Windows Server Backup) CSV ile uyumludur ama üçüncü parti bir backup yazılımı eski bir yöntem kullanırsa “redirected mode” tetikleyebilir. Bu nedenle cluster ortamına özgü dokümanları takip edin.
- CSV Boyutu: Tek bir devasa CSV yerine, birkaç mantıklı boyutta CSV’ye bölmek daha iyi olabilir. Örneğin tüm VM’ler için 50 TB tek CSV yapmaktansa, 10’ar TB’lık 5 CSV yapmak yönetilebilirlik ve olası bir hata durumunda toparlanma süresi açısından iyidir (daha küçük CSV’nin check disk süresi vs. kısadır). Bazı üreticiler, 10 TB üstü CSV’lerin failover süresinin uzayabileceğini belirt.
- Quorum Disk vs CSV: Quorum için disk tanığı kullanacaksanız, bu LUN’ın CSV olarak eklenmemesi gerekir. Quorum diski cluster’ın ayrı bir kaynağı olarak kalmalı. CSV’ler, quorum hesabında düğüm gibi oy kullanmazlar; sadece normal depolama kaynaklarıdır.
Storage Spaces Direct (S2D) Ayarları
Eğer cluster’ınızı S2D ile kurduysanız, cluster storage yönetimi biraz farklı çalışır. S2D etkinleştirildiğinde cluster otomatik olarak yerel disklerden bir Storage Pool oluşturur ve bunun üzerine CSV formatında bir veya birden fazla “Volume” yaratılır (ReFS kullanılır). Her volume, tıpkı normal CSV gibi C:\ClusterStorage\VolumeN altında görünür. S2D ortamında dikkat edilmesi gerekenler:
Network
S2D, veri replikasyonu için cluster içi ağı yoğun kullanır. Bu nedenle iki adet 10 Gbps veya daha hızlı RDMA destekli NIC genelde şarttır (Switch Embedded Teaming ile). S2D cluster’larda ayrı bir depolama ağı kavramı yoktur; cluster ağı aynı zamanda depolama replikasyon ağıdır. Bu ağda düşük gecikme ve yüksek throughput sağlanmalıdır.
Dynamic Quorum
S2D cluster’ları genelde 2 veya 3+ düğümlü olur. 2 düğümlü S2D’de özel bir “USB Witness” veya benzeri kullanılabilir. 3 ve üzeri S2D cluster’larda da bir tanık önerilir (hatta Azure Stack HCI gibi çözümlerde genelde bulut tanığı kullanılır).
Bakım Modu
S2D’de disk ve node bakımları için “Maintenance Mode” komutları kullanılır ki CAU bunu otomatik yapabilir. Yine de, S2D’nin tavsiye ettiği güncelleme sırası vs. dokümantasyonuna bakmak gerekir.
İzleme
S2D katmanında Storage Pool Quorum ayrı bir mekanizmadır (pool quorum, disklerin yarısından fazlası erişilebilir olmalı mantığı). Disk arızalarını bu gözle takip etmek gerekir.
S2D kendi başına kapsamlı bir konu olduğundan, özetle: S2D kullanırken cluster yönetim araçları (Windows Admin Center veya PowerShell) ile disk durumlarını ve kapasiteyi yakından izleyin, Microsoft’un S2D en iyi uygulamalar kılavuzuna kesinlikle göz atın. Örneğin NVMe/SATA karma disk yapısı, “Cache %10 kapasite olmalı” kuralı, iki düğüm cluster’da USB tanık kullanımı gibi konular kritik olabilir.
Diğer Özel Ayarlar ve Optimizasyonlar
Yukarıdaki başlıklarda ana konular ele alındıktan sonra, cluster performansını ve kararlılığını artırmaya yardımcı olabilecek bazı ek ipuçları şöyledir:
Cluster RegisterAllProvidersIP
Eğer cluster’ınız multi-subnet (farklı IP ağlarında düğümler) bir yapıdaysa ve istemci bağlantıları için DNS round-robin kullanılıyorsa, cluster adı için DNS’de birden fazla IP kaydı tutulabilir. Böyle durumlarda Cluster Name kaynak ayarlarında RegisterAllProvidersIP ve HostRecordTTL gibi parametreler bulunmaktadır. Multi-subnet AlwaysOn/SQL vb. senaryolarında RegisterAllProvidersIP=0 (sadece aktif IP’yi kaydet) tercih edilebilir. Tek subnet cluster’da bu genelde gerekmez.
DNS ve AD Güncelleme Ayarları
Cluster Name Object (CNO) bazen AD üzerinde belirli izinlerle oluşturulur. Eğer cluster adını değiştirme veya yeniden oluşturma gerekirse AD’de eski obje silinip yenisine izin vermeyi unutmayın. Ayrıca DNS’de eski kayıt kalmamasına dikkat edin.
Cluster Log Seviyesi
Varsayılan cluster log (cluster.log) ayrıntı seviyesi genelde yeterlidir. Ancak sorun gidermede daha fazla bilgi gerekiyorsa, Set-ClusterLog -Level 5 gibi bir komutla log seviye artırılabilir. Bu sadece geçici olarak yapılmalıdır, zira ayrıntılı log performansı bir miktar etkileyebilir.
Önemli olan, cluster kurulumunu tamamladıktan sonra kapsamlı testler yapmaktır. Planlı bir failover denemesi, network kesintisi simulasyonu, disk arızası simulasyonu gibi testlerle cluster’ın beklendiği gibi davrandığını doğrulayın. Bu, olası eksik ayarları veya sorunlu yapılandırmaları proaktif ortaya çıkaracaktır. Bu yazımda Failover Cluster spesifik ayarlar ve optimizasyonlar şeklinde bölüm 3 olarak bahsettim. Faydalı olması dileğiyle.
