Bu yazının devamında bir Azure bölgesinin tamamında meydana gelebilecek planlı yada plansız kesintilerde AVD servisinin devamlılığı için neler yapabileceğimizden bahsediyor olacağız. İş sürekliliği ve felaket kurtarma senaryolarında AVD servisinin devamlılığı için planlamamız gereken ana bileşenler şu şekildedir;
- AD DS ve Azure AD DS
- Host Pool
- Virtual Network
- Kullanıcı Profilleri
->AD DS ve Azure AD DS
Active Directory Domain Services yada Azure Active Directory Domain Service AVD’nin olmazsa olmazıdır. Bu servislerde meydana gelebilecek bir kesinti sonucu kullanıcılar AVD servisine kimlik doğrulaması yapamazlar. AVD servisi için gerekli olan Active Directory Domain Servisi yani Etki alanı denetleyicisi Azure üzerinde bir VM, on-premises’de bulunan bir sanal makina yada Azure Active Directory Domain servisi olabilir.
Eğer etki alanı denetliyiniz Azure’da bir VM ise: Farklı bir Azure bölgesine ek etki alanı denetleyicisi (Additional Domain Controller) dağıtmanız ve Azure bölgeleri arasında Peering yada Vnet-to-Vnet VPN ile network bağlantısı sağlamalıdır.
Eğer etki alanı denetliyiciniz On-premises ise: Fekalet anında alternatif olarak kullanacağınız Azure bölgesi ile on-premises arasında networksel bağlantıyı VPN, veya Express Route kullanarak sağlanmalıdır.
Eğer etki alanı denetliyiniz Azure AD DS ise: Varsayılan olarak aynı Azure bölgesi içerisinde en az iki tane etki alanı denetliyicileri availability zone içerisinde tutulur. Birbirinin kopyası olan bu etki alanı deneyleyicisine replica set adı verilir. Azure bölgesinde meydana gelecek bir felaket anında kesinti yaşamamak için farklı bir Azure bölgesinde ekstra replica set’ler (en fazla 5 tane) oluşturulabilir. Birden fazla replica set için Azure AD DS SKU’nuzunda Enterprise olması gereklidir. Replica Set nasil oluşturulur buradan inceleyebilirsiniz.
->Host Pool
Azure bölgesinin tamamında meydana gelebilecek bir kesintide hizmet kesintisi yaşamamak için host pool dağıtımı iki farklı şekilde planlanabilir:
Active-Active:
Tek bir Pooled host pool içerisine farklı Azure bölgelerinde bulunan session host makinaları dağıtılabilir. Bu senaryoda kullanıcı profillerinin her iki bölgeyede aktif olarak replike edilebilmesi için FSLogix Cloud Cache kullanılabilir.
| Bu yöntemde kullanıcıların lokasyonuna bakılmazsınız kullanıcılar her iki Azure bölgesindeki Session Host makinasına yönlendirilebilir ki bu durumda West Europe’de bulunan bir kullanıcının North Europe’ta bulunan Session Host makinası login olması performansı sorunlarına neden olabilir. |
Active-Passive:
- Azure Site Receovery ile makinalarınız ikincil Azure bölgesine replike edebilirsiniz. Bu senaryoda ikinci Azure bölgesinde host pool, app grup ve workspace oluşturmanız gerekir. Ayrıca bu senaryoda felaket anında ayağa kaldırdığınız makinalar sahip olduğu security token ile kendine en yakın host pool içerisine otomatik olarak Session host olarak register edecektir.
- ikincil Azure bölgesinde yeni bir host pool, App group ve workspace oluşturup felaket anına kadar tüm kaynaklarınızı kapalı tutabilirsiniz.
- Her iki Azure bölgesindede session host makinalarının bulunduğu bir host pool oluşturup ikincil bölgede bulunan makinaları felaket anına kadar kapalı tutabilirsiniz.
| Her senaryoda ikicinil Azure bölgesinde bir etki alanı denetleyicisi olması gerektiğini unutulmamalıdır. |
->Virtual Network
Sahip olduğunuz Azure network’ü bölgesel kesintilerden doğrudan etkileneceğinden ikincil bir Azure bölgesinde network planlaması yapılmalıdır. İkincil bölgede manual olarak bir network oluşturulup peering yada vnet-to-net kullanarak birbirine bağlayabilir yada Mevcut network ayarlarınızı korumak için Azure Site Recovery’i kullanabilirsiniz. Eğer AVD ortamınızın on-premises kaynaklarınız ile bir bağımlılığı varsa (File Server, AD DS, DNS gibi) ikincil bölge ve on-premises arasındaki networksel bağlantıda Express route, VPN, Virtual WAN ile sağlanmalıdır.
->Kullanıcı Profilleri
Felaket anında kullanıcı profillerinin kullanılabilirliği için seçeceğiniz yöntem Host Pool dağıtımıza göre değişiklik gösterektir:
Active-Passive Host Pool: Host Pool dağıtımı ile GRS Azure Standard Storage yada Azure NetApp file ile koruma sağlayabilirsiniz her ikiside Azure bölgeleri arası replikasyonu deskteklemekte.
Geo-Redundant Storage (GRS); LRS storage’da olduğu gibi verilerinizi eş zamanlı olarak aynı Azure bölgesi içerisindeki üç farklı veri merkezine eş zamanlı olarak kopyaladıktan sonra farklı bir Azure bölgesine verilerinizi kopyalar. Ayrıca FSlogix ajanının üzerinden birden fazla profil lokasyonu belirtebilir. Bu durumda ilk Azure bölgesine erişilememi durumunda FSlogix ajanı diğer Azure bölgesi üzerinde bulunan profillere erişmeye çalışacaktır.
Azure File Share Premium ve Azure Files + Large files ile GRS desteklenmemektedir bu durumda kullanacağınız storage account Standard olmalıdır. Eğer standard storage IOPS gereksinimlerinizi karşılamıyorsa Cloud Cache tercih edilebilir.
Active-Active Host Pool: Eğer Active-Active bir host pool dağıtımınız mevcutsa, kullanıcı verilerinin her iki lokasyondada eşit ve ulaşılabilir olması için yine Cloud Cache kullanılabilir. Cloud cache ile ilgili ayrıntı bilgi için buradan yararlanabilirsiniz.
Azure Virtual Desktop: Disaster Recovery – DataCenter Failure
