Microsoft AZ-801: Olağanüstü Durum Kurtarma ve İş Sürekliliği — Çalışma kılavuzu
Şunun bir parçası: Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.
Genel Bakış
Felaket kurtarma (FK) ve iş sürekliliği (İS) tasarımı, iki metriğin ölçülmesiyle başlar: Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO). RTO, hizmeti ne kadar hızlı geri yüklemeniz gerektiğini temsil eder; RPO ise ne kadar (zamansal) veri kaybının kabul edilebilir olduğunu tanımlar. Bu değerler teknoloji seçimlerini, topolojiyi ve maliyeti belirler. Düşük RTO, orkestrasyon ve otomasyonu (Azure Site Recovery kurtarma planları, runbook’lar ve önceden oluşturulmuş hedef kaynaklar) destekler. Düşük RPO, sürekli replikasyonu (ASR) veya senkron işleme (SQL Always On) tercih ederken, daha yüksek RPO periyodik yedeklemelere (Azure Backup, Windows Server Backup) dayanabilir. Çoklu VM tutarlılık grupları ve uygulama tutarlı anlık görüntüler, katı bir RPO gerektiğinde sanal makineler arası işlem bütünlüğünü korur. Kasa seçimi (Recovery Services kasası vs Backup kasası), replikasyon ilkesi tasarımı ve yedekleme zamanlaması, aşırı harcama yapmadan bu hedefleri karşılamak üzere seçilir.
Azure Site Recovery: Hyper-V, VMware, orkestrasyon ve tutarlılık
Azure Site Recovery (ASR), şirket içi VMware, Hyper-V ve Azure IaaS VM’leri için sürekli replikasyon ve orkestre edilmiş yük devretme/geri yük devretme sağlar.
Hyper-V koruması
- Replikasyon ilkesi: RPO eşiğini, kurtarma noktası saklama süresini ve uygulama tutarlı anlık görüntü sıklığını tanımlar. Örneğin, RPO eşiğini 15 dakikaya ayarlayın, belirli bir zamana geri dönmek için kurtarma noktalarını 24–72 saat saklayın ve her 1–4 saatte bir uygulama tutarlı anlık görüntüler alın. İlkeler, bant genişliği kısıtlamasını ve sıkıştırmayı kontrol eder; ilişkili VM’lerin kurtarma noktalarının hizalanması için çoklu VM tutarlılığı etkinleştirilebilir.
- Kurtarma noktaları: ASR, sürekli olarak kilitlenme anıyla tutarlı noktalar ve VSS ile sessizleştirme (quiescing) başarılı olduğunda ek uygulama tutarlı noktalar tutar. Saklama süresi, mantıksal bozulmayı veya fidye yazılımını azaltmak için daha önceki noktaları seçmenize olanak tanır.
- Test yük devretme: Kesintisiz tatbikatlar, runbook’ları, önyükleme sırasını ve ağ yapılandırmasını doğrular. Yalıtılmış bir VNet kullanın, test giriş değerleri (ör. DNS IP’leri) sağlayın ve ad çözümlemenin yalıtılmış olduğundan emin olun. Üretim replikasyonu etkilenmeden devam eder ve doğrulama sonrası temizleme işlemi test yapılarını kaldırır. IP çakışmalarını önlemek için ağ eşlemesini ve test NIC eşlemelerini önceden oluşturun.
VMware koruması
- Yapılandırma sunucusu: Recovery Services kasasına kaydolan, vCenter/ESXi envanterini keşfeden, replikasyonu koordine eden ve Mobility Service aracılarını gönderen şirket içi cihazdır. VMware koruması için kontrol düzlemidir.
- İşlem sunucusu: Genellikle başlangıçta yapılandırma sunucusuyla aynı yerde bulunur; değişiklik takibi, sıkıştırma, şifreleme ve Azure’a veri aktarımı gerçekleştirir. Verim (throughput) için ve gecikmeyi en aza indirmek amacıyla gelen veri trafiğini (ingress) korunan ana makinelere yakın konumlandırmak için ölçeği genişletilebilir (scale-out) işlem sunucuları eklenir.
- Ana hedef sunucusu: Azure’dan VMware’e geri yük devretme (failback) için kullanılır. Yeniden koruma (re-protect) sırasında çoğaltılan değişiklikleri alır ve iş yüklerini vSphere’e geri yükleyebilmeniz için bir iniş bölgesi (landing zone) sağlar. Depolamayı, geri yük devretme sırasındaki toplam yazma hızına göre boyutlandırın ve ağ veriminin en yoğun yeniden senkronizasyon pencereleriyle eşleştiğinden emin olun.
- Mobility Service: Disk değişikliklerini yakalamak için korunan her VM’ye yüklenir. Kimlik bilgilerini veya gönderme (push) mekanizmalarını güncel tutun ve kasadaki aracı (agent) sağlığını izleyin.
Orkestrasyon ve tutarlılık
- Kurtarma planları: Gruplamaları, önyükleme sırasını, manuel onay adımlarını ve otomasyon görevlerini tanımlayan, FK için bildirimsel (declarative) runbook’lardır. NSG’leri yeniden yapılandırmak, DNS kayıtlarını güncellemek, uygulama önbelleklerini ısıtmak veya SQL betiklerini çalıştırmak için Azure Automation runbook’larını kullanın. “Veri”, “Uygulama” ve “Web” katmanları gibi mantıksal gruplar atayın ve doğrulama için duraklamalar ekleyin.
- Runbook’lar: Yanlış uyarıları azaltmak için yük devretme sırasında traffic manager uç noktalarını değiştirmek, PaaS bağımlılıklarını ölçeklendirmek veya şirket içi izlemeyi devre dışı bırakmak gibi ortama özgü görevleri otomatikleştirin. Bunları test ve üretim yük devretme senaryoları için parametrelendirin.
- Çoklu VM tutarlılık grupları: Aynı yazma sırasını paylaşan katmanlar (ör. uygulama sunucusu ve veritabanı günlük yazıcısı) için etkinleştirin. Bu, VM’ler arasında zaman içinde tutarlı bir nokta sağlar; doğruluk için verimden (throughput) ödün verir ve yalnızca gerçekten birbirine bağımlı VM’lerle sınırlandırılmalıdır.
RTO/RPO etkisi
- Sıkı RPO: Agresif replikasyon ve uygulama tutarlı anlık görüntüler içeren ASR’yi, verim için boyutlandırılmış işlem sunucularını ve adanmış replikasyon ağlarını tercih edin. Veritabanları için, bir metro alanı içinde Always On senkron işleme (synchronous commit) seçeneğini değerlendirin.
- Sıkı RTO: Hedef VNet’leri, alt ağları ve yük dengeleyicileri önceden oluşturun; manuel adımları ortadan kaldırmak için otomasyonlu kurtarma planları kullanın. Beklenen RTO için bir temel oluşturmak üzere test yük devretmelerini düzenli olarak kullanın.
Uygulama Seviyesi HA: SQL Always On ve DFS Replication
Bazı iş yükleri, RTO/RPO’ya bağlı olarak hipervizör seviyesindeki DR’yi tamamlayan veya yerini alan yerel replikasyon gerektirir.
Always On Availability Groups (AGs)
- Senkron ve asenkron commit: Senkron commit, birincil sunucudaki işlemi commit etmeden önce ikincil sunucunun log’u kalıcı hale getirmesini bekler; bu, gecikme ve iş hacmi (throughput) pahasına neredeyse sıfır veri kaybı (düşük RPO) sağlar. Düşük gecikmeli bağlantılarda (genellikle metro alan ağları) kullanılmalıdır. Asenkron commit ikincil sunucuyu beklemez, bu da WAN bağlantıları üzerinden daha yüksek performans sağlarken yük devretme sırasında potansiyel veri kaybı riskini (daha yüksek RPO) artırır.
- Otomatik yük devretme koşulları: Otomatik yük devretme, otomatik yük devretmenin etkinleştirildiği ve senkronize edilmiş en az iki senkron commit replikası gerektirir. Windows Server Failover Clustering, düğüm/servis sağlığını izler; SQL Server’ın esnek yük devretme ilkesi, hata koşulu seviyelerini (süreç çökmelerinden ciddi I/O sorunlarına kadar) tanımlar. Birincil veritabanının şüpheli olduğu durumlarda yük devretmeyi zorlamak için veritabanı sağlık tespiti etkinleştirilebilir. Quorum ve witness tasarımı, split-brain (bölünmüş beyin) durumunun önlenmesini sağlar; hızlı istemci yeniden bağlantısı için kurtarma sitesinde DNS ve listener IP’lerinin hazır olduğundan emin olun.
DFS Replication (DFSR)
- Replikasyon grupları ve bağlantılar: Replikasyon grubu, bir veya daha fazla replike edilmiş klasörü replike eden bir sunucu kümesidir. Bağlantılar, topolojiyi (full mesh, hub-spoke) ve zamanlama/bant genişliği kısıtlamasını tanımlar. Ölçeklenebilirlik ve daha kolay sorun giderme için hub-spoke modelini kullanın.
- Hazırlık alanı (Staging area): DFSR, Remote Differential Compression (RDC) için delta dosyalarını tutmak üzere her replike edilmiş klasör için bir hazırlık alanı kullanır. Hazırlık alanını en az en büyük dosyanızın boyutunda ve genellikle beklenen günlük değişimin 1-2 katı olarak boyutlandırın; yetersiz boyutlandırma aşırı temizleme ve yeniden denemelere neden olarak RPO/RTO’ya zarar verir.
- Çakışma çözümü: DFSR, çoklu ana (multi-master) bir yapıdadır. Eş zamanlı düzenlemeler meydana geldiğinde, DFSR sürüm vektörleri ve zaman damgaları kullanır; son yazan kazanır ve kaybeden kopya ConflictAndDeleted klasörüne (alanı kota ile yönetilir) taşınır. İlk veri doldurma (seeding) sırasında başlangıç çakışmalarını önlemek için, yalnızca ilk senkronizasyon için bir birincil üye ayarlayın. Tek yönlü senaryolar için salt okunur (read-only) replike edilmiş klasörler kullanın. Birikmeleri
dfsrdiagile izleyin ve RPO’yu karşılamak için zamanlamaları ayarlayın.
RTO/RPO ve entegre DR planlarının mimari üzerindeki etkisi
- Agresif RPO: Senkron veritabanı replikasyonunu veya yüksek frekanslı değişiklik işleme ve uygulama tutarlı anlık görüntüler (snapshot) içeren ASR’ı tercih edin. Replikasyon trafiğini izole edin ve işlem sunucularını (process server) ölçeklendirin. Çoklu VM tutarlılık gruplarını (multi-VM consistency groups) yalnızca sıkı sıkıya bağlı katmanlar için idareli kullanın.
- Agresif RTO: Hedef VNet’leri, alt ağları (subnet), Yönlendirme Tablolarını (Route Table) ve NSG’leri önceden hazırlayın; kurtarma planları (recovery plan) ve runbook’lar aracılığıyla IP yeniden atamalarını ve DNS güncellemelerini betikleyin (script). Altın imajları (golden image) ve VM boyutlarını kapasitesi mevcut olan SKU’lara sabitleyin. Yük devretmeleri (failover) üç ayda bir ve önemli değişikliklerden sonra test edin.
- Veri koruma katmanlaması: Hem yıkıcı arızaları hem de mantıksal bozulmaları ele almak için ASR’ı (hızlı hizmet kurtarma) Azure Backup (belirli bir zamana geri alma) ile birleştirin. Etki alanı denetleyicileri (domain controller) için, USN geri alma (rollback) açısından güvenli kurtarmayı doğrulamak amacıyla System State yedeklemelerini (MARS veya WSB) ASR/test yük devretmeleri ile eşleştirin. Dosya hizmetleri için DFSR, site içi/siteler arası yüksek erişilebilirlik sağlarken, Azure Backup fidye yazılımlarına (ransomware) karşı dayanıklı kurtarma sunar.
Pratik Problem Senaryosu
Küresel bir üretici olan Fabrikam, Inc., karma bir ortam işletmektedir: ERP uygulama katmanları için Hyper-V, eski ara katman yazılımları (legacy middleware) için VMware, veritabanları için SQL Server 2019 AG’leri ve DFS Replication kullanan büyük Windows dosya sunucuları. İş birimleri, ERP için RTO ≤ 1 saat ve RPO ≤ 15 dakika talep etmektedir; diğer iş yükleri RTO 4 saat, RPO 24 saati tolere edebilir.
- İş yüklerini ve RTO/RPO hedeflerini sınıflandırın
- ERP uygulama/web VM’leri ve SQL AG’leri Tier 1 (RTO 1s, RPO 15dk) olarak işaretlenir. Ara katman yazılımları ve dosya hizmetleri Tier 2/3’tür.
- Neden: En katı hedeflerin replikasyon ve orkestrasyon seçimlerini yönlendirmesini sağlar.
- Hyper-V ERP katmanları için ASR’ı uygulayın
- Hyper-V ana bilgisayarlarına ASR Provider’ı kurun ve bir Recovery Services kasasına kaydedin. 15 dakikalık RPO eşiği, saatte bir uygulama tutarlı anlık görüntüler ve 48 saatlik saklama süresi ile bir replikasyon ilkesi oluşturun. SQL dinleyicisi (listener) ile işlem paylaşan ERP uygulama sunucuları arasında bir çoklu VM tutarlılık grubu (multi-VM consistency group) etkinleştirin.
- Neden: Sürekli replikasyon ve uygulama tutarlı kontrol noktaları, katmanı tutarlı tutarken 15 dakikalık RPO hedefine ulaşır.
- VMware ara katman yazılımı için ASR’ı uygulayın
- Şirket içinde, öngörülen değişiklik oranına (churn) göre boyutlandırılmış ve birlikte konumlandırılmış bir işlem sunucusu (process server) ile bir yapılandırma sunucusu (configuration server) dağıtın. En büyük siteye yatay ölçeklenen bir işlem sunucusu (scale-out process server) ekleyin. Korunan VM’lere Mobility Service’i kurun. Olası bir geri devretme (failback) için bir ana hedef sunucu (master target server) hazırlayın.
- Neden: ASR VMware mimarisi, güvenilir değişiklik yakalama ve şirket içi site kurtarıldığında kontrollü bir geri devretme yolu sağlar.
- Kurtarma planları ve runbook’lar ile orkestrasyon yapın
- Önce SQL (veri), sonra ERP uygulama, sonra da web katmanlarını gruplayan bir kurtarma planı (recovery plan) oluşturun. Şunları yapmak için Azure Automation runbook’ları ekleyin: NSG’leri yeniden yapılandırmak, özel DNS bölgelerini (private DNS zones) Azure IP’lerini gösterecek şekilde güncellemek ve Traffic Manager uç noktalarını değiştirmek. Web’i çevrimiçi hale getirmeden önce manuel bir doğrulama adımı ekleyin.
- Neden: Otomasyon, RTO’yu kısaltır ve bir kriz sırasında insan hatasını azaltır, doğru önyükleme sırasını ve ağ durumunu zorunlu kılar.
- SQL Server’ı siteye göre ayarlanmış AG’ler ile koruyun
- Sıfıra yakın RPO için birincil ve bir ikincil kopyayı metro bölgesi içinde senkron işlemede (synchronous commit) tutun; uzak bir DR ikincil kopyasını asenkron işlemede (asynchronous commit) tutun. Veritabanı sağlık tespiti etkinken senkron kopyalar arasında otomatik yük devretmeyi yapılandırın. Çapraz görünürlük için AG yük devretme adımlarını ASR kurtarma planına entegre edin.
- Neden: Senkron AG’ler veritabanı katmanı için en düşük RPO’yu sunar; ASR ise bunun etrafında site orkestrasyonu sağlar.
- Yedeklemeleri Azure Backup ile katmanlandırın
- Dosya ve System State koruması gerektiren şirket içi Windows sunucuları için MARS aracısını dağıtın ve günlük yedeklemeler ve 30/52/7 (günlük/haftalık/yıllık) saklama süresi ile ilkeler yapılandırın. Şifreleme parolasını Azure Key Vault’ta (HSM destekli) saklayın ve koruyun. Gerekirse tam yeniden oluşturmayı sağlamak için kritik uygulama sunucuları için BMR imajlarını yakalamak üzere MABS kullanın. Kasada geçici silme (soft delete) ve güvenlik PIN’ini etkinleştirin.
- Neden: Belirli bir zamana kurtarma, mantıksal bozulmaya ve fidye yazılımlarına karşı koruma sağlayarak ASR’ın hızlı yük devretmesini tamamlar.
- DFSR’ı ve dosya hizmetleri yedeklemesini güçlendirin
- Replikasyon grubu topolojisini (hub-spoke) gözden geçirin, hazırlık alanlarının (staging area) günlük değişiklik oranının 1,5 katı boyutunda olduğundan emin olun ve bölge içinde neredeyse gerçek zamanlı replikasyonu sürdürmek için zamanlamaları ayarlayın. Uzun süreli saklama ve alternatif konuma kurtarma testleri için paylaşımları MARS/MABS ile koruyun.
- Neden: Doğru DFSR ayarı günlük kullanılabilirliği karşılarken, yedeklemeler geri alma güvenliği sağlar.
- Test yük devretmeleri ve belgelenmiş runbook’lar ile doğrulayın
- Üç ayda bir izole bir VNet’e ASR test yük devretmeleri gerçekleştirin, ERP işlevselliğini maskelenmiş verilere karşı doğrulayın ve RTO’yu ölçün. Geri yükleme tatbikatları yapın: MARS alternatif konuma geri yüklemeleri ve MABS’tan bir sanal alana (sandbox) tam bir BMR kurtarması.
- Neden: Düzenli tatbikatlar planı kanıtlar, yapılandırma kaymalarını ortaya çıkarır ve yönetime RTO/RPO ile uyumluluğun kanıtını sunar.
Bu tasarım Fabrikam’ın hedeflerini karşılamaktadır: ASR bir saatin altında RTO sağlar, senkron moddaki SQL AG’leri veritabanları için RPO’yu en aza indirir ve MARS/MABS ile Azure Backup güvenli, belirli bir zamana kurtarma ve tam makine yeniden oluşturma yeteneği sunar. Kurtarma planları ve runbook’lar olaylar sırasında belirsizliği ortadan kaldırır ve DFSR, yedeklemeler arasında operasyonel süreklilik için optimize edilmiş olarak kalır.
← Hyper-V · Tüm alanlar · Hibrit Ortamlar için Kimlik ve Erişim Yönetimi →
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →