Azure Sanal Masaüstü için Çoklu Bölge İş Sürekliliği ve Olağanüstü Durum Kurtarma (BCDR)

Azure Sanal Masaüstü, Microsoft Azure üzerinde çalışan kapsamlı bir masaüstü ve uygulama sanallaştırma hizmetidir. Sanal Masaüstü, kuruluşların iş dayanıklılığını güçlendirmelerine yardımcı olan güvenli bir uzak masaüstü deneyimine yardımcı olur. Basitleştirilmiş yönetim, Windows 10 ve 11 Enterprise çoklu oturumu ve Kurumlar için Microsoft 365 Uygulamaları için iyileştirmeler sunar. Sanal Masaüstü ile Windows masaüstü ve uygulamalarınızı Azure'da dakikalar içinde dağıtabilir ve ölçeklendirerek uygulamalarınızın ve verilerinizin güvenliğini sağlamaya yardımcı olacak tümleşik güvenlik ve uyumluluk özellikleri sağlayabilirsiniz.

Sanal Masaüstü ile kuruluşunuz için uzaktan çalışmayı etkinleştirmeye devam ettikçe olağanüstü durum kurtarma (DR) özelliklerini ve en iyi yöntemlerini anlamak önemlidir. Bu uygulamalar, verilerin güvenli ve çalışanların üretken kalmasına yardımcı olmak için bölgeler arasında güvenilirliği güçlendirir. Bu makalede iş sürekliliği ve olağanüstü durum kurtarma (BCDR) önkoşulları, dağıtım adımları ve en iyi yöntemler hakkında önemli noktalar sunulmaktadır. Seçenekler, stratejiler ve mimari kılavuzu hakkında bilgi ediniyorsunuz. Bu belgedeki içerik, başarılı bir BCDR planı hazırlamanıza olanak tanır ve planlı ve plansız kapalı kalma olayları sırasında işletmenize daha fazla dayanıklılık getirmenize yardımcı olabilir.

Birkaç tür olağanüstü durum ve kesinti vardır ve her birinin farklı bir etkisi olabilir. Dayanıklılık ve kurtarma, hizmetin farklı bir uzak Azure bölgesinde kurtarılması da dahil olmak üzere hem yerel hem de bölge genelindeki olaylar için ayrıntılı olarak ele alınıyor. Bu tür bir kurtarma, coğrafi olağanüstü durum kurtarma olarak adlandırılır. Dayanıklılık ve kullanılabilirlik için Sanal Masaüstü mimarinizi oluşturmak çok önemlidir. Hata olaylarının etkisini azaltmak için en yüksek yerel dayanıklılığı sağlamanız gerekir. Bu dayanıklılık, kurtarma yordamlarını yürütme gereksinimlerini de azaltır. Bu makalede ayrıca yüksek kullanılabilirlik ve en iyi yöntemler hakkında bilgi sağlanır.

Hedefler ve kapsam

Bu kılavuzun hedefleri şunlardır:

• Seçilen önemli kullanıcı verileri için veri kaybını en aza indirirken maksimum kullanılabilirlik, dayanıklılık ve coğrafi olağanüstü durum kurtarma özelliği sağlayın.
• Kurtarma süresini en aza indirin.

Bu hedefler kurtarma noktası hedefi (RPO) ve Kurtarma Süresi Hedefi (RTO) olarak da bilinir.

Önerilen çözüm yerel yüksek kullanılabilirlik, tek bir kullanılabilirlik alanı hatasına karşı koruma ve tüm Azure bölgesi hatasına karşı koruma sağlar. Hizmeti kurtarmak için farklı veya ikincil bir Azure bölgesinde yedekli dağıtıma dayanır. Yine de iyi bir uygulama olsa da, Sanal Masaüstü ve BCDR oluşturmak için kullanılan teknoloji, Azure bölgelerinin eşleştirilmesine gerek duymaz. Ağ gecikme süresi izin verirse birincil ve ikincil konumlar herhangi bir Azure bölgesi birleşimi olabilir. AVD konak havuzlarının birden çok coğrafi bölgede çalıştırılması BCDR ile sınırlı olmayan daha fazla avantaj sunabilir.

Tek bir kullanılabilirlik alanı hatasının etkisini azaltmak için, yüksek kullanılabilirliği geliştirmek için dayanıklılığı kullanın:

• İşlem katmanında Sanal Masaüstü oturum konaklarını farklı kullanılabilirlik alanlarına dağıtın.
• Depolama katmanında mümkün olduğunca bölge dayanıklılığını kullanın.
• Ağ katmanında, bölgeye dayanıklı Azure ExpressRoute ve sanal özel ağ (VPN) ağ geçitlerini dağıtın.
• Her bağımlılık için tek bir bölge kesintisinin etkisini gözden geçirin ve azaltmaları planlayın. Örneğin, sanal masaüstü kullanıcıları tarafından erişilen Active Directory Etki Alanı Denetleyicilerini ve diğer dış kaynakları birden çok kullanılabilirlik alanına dağıtın.

Kullandığınız kullanılabilirlik alanı sayısına bağlı olarak, bir bölgenin kaybını telafi etmek için oturum konaklarının sayısının fazla sağlanmasını değerlendirin. Örneğin, kullanılabilir (n-1) bölgelerde bile kullanıcı deneyimini ve performansını sağlayabilirsiniz.

Bazı bölgelerdeki olası tür birleşimleri, çoğaltma seçenekleri, hizmet özellikleri ve kullanılabilirlik kısıtlamaları nedeniyle, depolamaya özgü çoğaltma mekanizmaları yerine FSLogix'in Cloud Cache bileşeninin kullanılması önerilir.

OneDrive bu makalede ele alınmıyor. Yedeklilik ve yüksek kullanılabilirlik hakkında daha fazla bilgi için bkz . Microsoft 365'te SharePoint ve OneDrive veri dayanıklılığı.

Bu makalenin geri kalanında iki farklı Sanal Masaüstü konak havuzu türüne yönelik çözümler hakkında bilgi edineceksiniz. Bu mimariyi diğer çözümlerle karşılaştırabilmeniz için sağlanan gözlemler de vardır:

• Kişisel: Bu tür konak havuzunda, kullanıcının kalıcı olarak atanmış bir oturum konağı vardır ve bu durum hiçbir zaman değişmemelidir. Kişisel olduğundan, bu VM kullanıcı verilerini depolayabilir. Varsayım, durumu korumak ve korumak için çoğaltma ve yedekleme tekniklerini kullanmaktır.
• Havuza alındı: Kullanıcılara, doğrudan bir masaüstü uygulama grubu aracılığıyla veya uzak uygulamalar kullanılarak havuzdaki kullanılabilir oturum ana bilgisayar VM'lerinden biri geçici olarak atanır. VM'ler durum bilgisi yoktur ve kullanıcı verileri ve profilleri dış depolama alanında veya OneDrive'da depolanır.

Maliyet etkileri tartışılır, ancak birincil hedef en az veri kaybıyla etkili bir coğrafi olağanüstü durum kurtarma dağıtımı sağlamaktır. DAHA fazla BCDR ayrıntısı için aşağıdaki kaynaklara bakın:

• Sanal Masaüstü için BCDR ile ilgili dikkat edilmesi gerekenler
• Sanal Masaüstü olağanüstü durum kurtarma

Önkoşullar

Temel altyapıyı dağıtın ve birincil ve ikincil Azure bölgesinde kullanılabilir olduğundan emin olun. Ağ topolojiniz hakkında rehberlik için Azure Bulut Benimseme Çerçevesi Ağ topolojisi ve bağlantı modellerini kullanabilirsiniz:

• Geleneksel Azure ağ topolojisi
• Sanal WAN ağ topolojisi (Microsoft tarafından yönetilir)

Her iki modelde de birincil Sanal Masaüstü konak havuzunu ve ikincil olağanüstü durum kurtarma ortamını farklı uç sanal ağlarına dağıtın ve bunları aynı bölgedeki her hub'a bağlayın. Birincil konuma bir hub, ikincil konuma bir hub yerleştirin ve ardından ikisi arasında bağlantı kurun.

Merkez sonunda şirket içi kaynaklara, güvenlik duvarı hizmetlerine, Active Directory Etki Alanı Denetleyicileri gibi kimlik kaynaklarına ve Log Analytics gibi yönetim kaynaklarına karma bağlantı sağlar.

İkincil konuma yük devredildiğinde iş kolu uygulamalarını ve bağımlı kaynak kullanılabilirliğini dikkate almanız gerekir.

Kontrol düzlemi iş sürekliliği ve olağanüstü durum kurtarma

Sanal Masaüstü, kesintiler sırasında müşteri meta verilerini korumak için kontrol düzlemi için iş sürekliliği ve olağanüstü durum kurtarma sunar. Azure platformu bu verileri ve işlemi yönetir ve kullanıcıların herhangi bir şey yapılandırmasına veya yürütmesine gerek yoktur.

Sanal Masaüstü, tek tek bileşenlerin hatalarına dayanıklı olacak ve hatalardan hızlı bir şekilde kurtulabilecek şekilde tasarlanmıştır. Bir bölgede kesinti oluştuğunda, hizmet altyapısı bileşenleri ikincil konuma yük devreder ve normal şekilde çalışmaya devam eder. Hizmetle ilgili meta verilere erişmeye devam edebilirsiniz ve kullanıcılar kullanılabilir konaklara bağlanmaya devam edebilir. Kiracı ortamı veya konaklar erişilebilir durumda kalırsa son kullanıcı bağlantıları çevrimiçi kalır. Sanal Masaüstü için veri konumları, konak havuzu oturumu konak sanal makineleri (VM) dağıtımının konumundan farklıdır. Sanal Masaüstü meta verilerini desteklenen bölgelerden birinde bulup vm'leri farklı bir konuma dağıtmak mümkündür. Diğer ayrıntılar Sanal Masaüstü hizmet mimarisi ve dayanıklılığı makalesinde verilmiştir .

Etkin-Etkin ve Aktif-Pasif karşılaştırması

Farklı kullanıcı kümelerinin farklı BCDR gereksinimleri varsa, Microsoft farklı yapılandırmalara sahip birden çok konak havuzu kullanmanızı önerir. Örneğin, görev açısından kritik bir uygulaması olan kullanıcılar coğrafi olağanüstü durum kurtarma özelliklerine sahip tam olarak yedekli bir konak havuzu atayabilir. Ancak geliştirme ve test kullanıcıları olağanüstü durum kurtarma olmadan ayrı bir konak havuzu kullanabilir.

Her sanal masaüstü konak havuzu için BCDR stratejinizi etkin-etkin veya etkin-pasif modeli temel alabilirsiniz. Bu senaryoda, bir coğrafi konumdaki aynı kullanıcı kümesinin belirli bir konak havuzu tarafından sunulduğu varsayılır.

• Etkin-Etkin

  • Birincil bölgedeki her konak havuzu için ikincil bölgeye ikinci bir konak havuzu dağıtırsınız.

  • Bu yapılandırma neredeyse sıfır RTO sağlar ve RPO'nun ek maliyeti vardır.

  • Bir yöneticinin müdahale etmesine veya yük devretmesine gerek yoktur. Normal işlemler sırasında ikincil konak havuzu kullanıcıya Sanal Masaüstü kaynakları sağlar.

  • Her konak havuzunun kalıcı kullanıcı profilleri için kendi depolama hesapları (en az bir) vardır.

  • Kullanıcının fiziksel konumuna ve kullanılabilir bağlantısına göre gecikme süresini değerlendirmeniz gerekir. Batı Avrupa ve Kuzey Avrupa gibi bazı Azure bölgelerinde birincil veya ikincil bölgelere erişilirken fark göz ardı edilebilir. Azure Sanal Masaüstü Deneyimi Tahmin Aracı aracını kullanarak bu senaryoyu doğrulayabilirsiniz.

  • Kullanıcılar, hem birincil hem de ikincil konak havuzlarında Masaüstü Uygulama Grubu (DAG) ve RemoteApp Uygulama Grubu (RAG) gibi farklı uygulama gruplarına atanır. Bu durumda, Sanal Masaüstü istemci akışlarında yinelenen girdiler görürler. Karışıklığı önlemek için, her kaynağın amacını yansıtan net adlara ve etiketlere sahip ayrı Sanal Masaüstü çalışma alanlarını kullanın. Kullanıcılarınıza bu kaynakların kullanımı hakkında bilgi verin.

    

  • FSLogix Profili ve ODFC kapsayıcılarını ayrı ayrı yönetmek için depolamaya ihtiyacınız varsa, neredeyse sıfır RPO sağlamak için Cloud Cache'i kullanın.

    • Profil çakışmalarını önlemek için, kullanıcıların aynı anda her iki konak havuzuna da erişmesine izin verme.
    • Bu senaryonun etkin-etkin yapısı nedeniyle, kullanıcılarınızı bu kaynakları doğru şekilde kullanma konusunda eğitmeniz gerekir.

• Aktif-Pasif
  • Etkin-etkin gibi, birincil bölgedeki her konak havuzu için ikincil bölgeye ikinci bir konak havuzu dağıtırsınız.
  • İkincil bölgede etkin işlem kaynaklarının miktarı, kullanılabilir bütçeye bağlı olarak birincil bölgeye göre azaltılır. Daha fazla işlem kapasitesi sağlamak için otomatik ölçeklendirmeyi kullanabilirsiniz, ancak daha fazla zaman gerektirir ve Azure kapasitesi garanti değildir.
  • Bu yapılandırma, etkin-etkin yaklaşımına kıyasla daha yüksek RTO sağlar, ancak daha ucuzdur.
  • Azure kesintisi olduğunda bir yük devretme yordamı yürütmek için yönetici müdahalesine ihtiyacınız vardır. İkincil konak havuzu normalde kullanıcıya Sanal Masaüstü kaynaklarına erişim sağlamaz.
  • Her konak havuzunun kalıcı kullanıcı profilleri için kendi depolama hesapları vardır.
  • Sanal Masaüstü hizmetlerini en iyi gecikme süresi ve performansla kullanan kullanıcılar yalnızca Azure kesintisi olduğunda etkilenir. Azure Sanal Masaüstü Deneyimi Tahmin Aracı aracını kullanarak bu senaryoyu doğrulamanız gerekir. İkincil olağanüstü durum kurtarma ortamı için performans düzeyi düşürülmüş olsa bile kabul edilebilir olmalıdır.
  • Kullanıcılar Masaüstü ve Uzak uygulamalar gibi yalnızca bir uygulama grubu kümesine atanır. Normal işlemler sırasında bu uygulamalar birincil konak havuzunda yer alır. Kesinti sırasında ve yük devretme sonrasında kullanıcılar ikincil konak havuzundaki Uygulama Gruplarına atanır. Kullanıcının Sanal Masaüstü istemci akışında yinelenen girdi gösterilmez, aynı çalışma alanını kullanabilirler ve her şey onlar için saydamdır.
  • FSLogix Profili ve Office kapsayıcılarını yönetmek için depolamaya ihtiyacınız varsa, neredeyse sıfır RPO sağlamak için Cloud Cache'i kullanın.
    • Profil çakışmalarını önlemek için, kullanıcıların aynı anda her iki konak havuzuna da erişmesine izin verme. Bu senaryo etkin-pasif olduğundan, yöneticiler bu davranışı uygulama grubu düzeyinde zorunlu kılabilir. Yalnızca bir yük devretme yordamından sonra kullanıcı ikincil konak havuzundaki her uygulama grubuna erişebilir. Birincil konak havuzu uygulama grubunda erişim iptal edilir ve ikincil konak havuzundaki bir uygulama grubuna yeniden atanır.
    • Tüm uygulama grupları için yük devretme yürütür, aksi takdirde farklı konak havuzlarında farklı uygulama grupları kullanan kullanıcılar, etkili bir şekilde yönetilmemesi durumunda profil çakışmasına neden olabilir.
  • Belirli bir kullanıcı alt kümesinin ikincil konak havuzuna seçmeli olarak yük devretmesine izin vermek ve sınırlı etkin-etkin davranış ve yük devretme testi özelliği sağlamak mümkündür. Belirli uygulama gruplarının yükünü devretmek de mümkündür, ancak kullanıcılarınızı farklı konak havuzlarından kaynakları aynı anda kullanmama konusunda eğitmeniz gerekir.

Belirli durumlarda, farklı bölgelerde bulunan oturum konaklarının bir karışımıyla tek bir konak havuzu oluşturabilirsiniz. Bu çözümün avantajı, tek bir konak havuzunuz varsa masaüstü ve uzak uygulamalar için yinelenen tanım ve atamalara gerek olmamasıdır. Ne yazık ki, paylaşılan konak havuzları için olağanüstü durum kurtarmanın çeşitli dezavantajları vardır:

• Havuza alınan konak havuzları için kullanıcıyı aynı bölgedeki bir oturum konağına zorlamak mümkün değildir.
• Bir kullanıcı, uzak bir bölgedeki bir oturum konağına bağlanırken daha yüksek gecikme süresi ve yetersiz performansla karşılaşabilir.
• Kullanıcı profilleri için depolama gerekiyorsa, birincil ve ikincil bölgelerdeki oturum konaklarının atamalarını yönetmek için karmaşık bir yapılandırmaya ihtiyacınız vardır.
• boşaltma modunu kullanarak ikincil bölgede bulunan oturum konaklarına erişimi geçici olarak devre dışı bırakabilirsiniz. Ancak bu yöntem daha karmaşıklık, yönetim yükü ve kaynakların verimsiz kullanımına neden olur.
• İkincil bölgelerde oturum konaklarını çevrimdışı durumda tutabilirsiniz, ancak daha karmaşıklık ve yönetim yükü getirir.

Önemli noktalar ve öneriler

Genel

Birden çok konak havuzu ve FSLogix bulut önbelleği mekanizması kullanarak etkin-etkin veya etkin-pasif yapılandırma dağıtmak için, modele bağlı olarak konak havuzunu aynı çalışma alanında veya farklı bir çalışma alanında oluşturabilirsiniz. Bu yaklaşım, hem konak havuzlarını eşitlenmiş hem de aynı yapılandırma düzeyinde tutarak hizalamayı ve güncelleştirmeleri korumanızı gerektirir. İkincil olağanüstü durum kurtarma bölgesi için yeni bir konak havuzuna ek olarak şunları yapmanız gerekir:

• Yeni konak havuzu için yeni ayrı uygulama grupları ve ilgili uygulamalar oluşturmak için.
• Birincil konak havuzuna kullanıcı atamalarını iptal etmek ve ardından yük devretme sırasında bunları yeni konak havuzuna el ile yeniden atamak için.

FSLogix için İş sürekliliği ve olağanüstü durum kurtarma seçeneklerini gözden geçirin.

• Bu belgede profil kurtarma kapsamına alınmamıştır.
• Bulut önbelleği (etkin/pasif) bu belgeye dahildir ancak aynı konak havuzu kullanılarak uygulanır.
• Bulut önbelleği (etkin/etkin) bu belgenin kalan bölümünde ele alınmıştır.

Sanal Masaüstü mimarisinin tasarımında dikkate alınması gereken Sanal Masaüstü kaynakları için sınırlar vardır. Tasarımınızı Sanal Masaüstü hizmet sınırlarına göre doğrulayın.

Tanılama ve izleme için hem birincil hem de ikincil konak havuzu için aynı Log Analytics çalışma alanını kullanmak iyi bir uygulamadır. Azure Sanal Masaüstü İçgörüleri, bu yapılandırmayı kullanarak her iki bölgede de dağıtımın birleşik bir görünümünü sunar.

Ancak, tek bir günlük hedefi kullanmak, birincil bölgenin tamamı kullanılamıyorsa sorunlara neden olabilir. İkincil bölge, kullanılamayan bölgede Log Analytics çalışma alanını kullanamaz. Bu durum kabul edilemezse aşağıdaki çözümler benimsenebilir:

• Her bölge için ayrı bir Log Analytics çalışma alanı kullanın ve ardından Sanal Masaüstü bileşenlerini yerel çalışma alanına doğru günlüğe kaydetmeye yönlendirin.
• Logs Analytics çalışma alanı çoğaltma ve yük devretme özelliklerini test edin ve gözden geçirin.

İşlem

• Birincil ve ikincil olağanüstü durum kurtarma bölgelerinde her iki konak havuzunun da dağıtımı için oturum konağı VM filonuzu birden çok kullanılabilirlik alanına yaymalısınız. Kullanılabilirlik alanları yerel bölgede kullanılamıyorsa, çözümünüzü varsayılan dağıtımdan daha dayanıklı hale getirmek için kullanılabilirlik kümesini kullanabilirsiniz.

• İkincil olağanüstü durum kurtarma bölgesinde konak havuzu dağıtımı için kullandığınız altın görüntü, birincil için kullandığınızla aynı olmalıdır. Görüntüleri Azure İşlem Galerisi'nde depolamalı ve hem birincil hem de ikincil konumlarda birden çok görüntü çoğaltması yapılandırmalısınız. Her görüntü çoğaltması, maksimum sayıda VM'nin paralel dağıtımını sürdürebilir ve istediğiniz dağıtım toplu iş boyutuna bağlı olarak birden fazla sanal makineye ihtiyacınız olabilir. Daha fazla bilgi için bkz . Azure İşlem Galerisi'nde görüntüleri depolama ve paylaşma.

  

• Azure İşlem Galerisi genel bir kaynak değildir. İkincil bölgede en az ikincil bir galeri olması önerilir. Birincil bölgenizde bir galeri, VM görüntü tanımı ve VM görüntü sürümü oluşturun. Ardından, ikincil bölgede de aynı nesneleri oluşturun. VM görüntüsü sürümünü oluştururken, birincil bölgede kullanılan galeriyi, VM görüntü tanımını ve VM görüntü sürümünü belirterek birincil bölgede oluşturulan VM görüntüsü sürümünü kopyalama olanağı vardır. Azure görüntüyü kopyalar ve yerel bir VM görüntüsü sürümü oluşturur. Aşağıda açıklandığı gibi Azure portalını veya Azure CLI komutunu kullanarak bu işlemi yürütmek mümkündür:

  Görüntü tanımı ve görüntü sürümü oluşturma

  az sig image-version create

• İkincil olağanüstü durum kurtarma konumlarındaki tüm oturum ana bilgisayar VM'leri sürekli etkin ve çalışır durumda olmamalıdır. Başlangıçta yeterli sayıda VM oluşturmanız gerekir ve bundan sonra Planları ölçeklendirme gibi bir otomatik ölçeklendirme mekanizması kullanın. Bu mekanizmalarla, maliyetleri azaltmak için işlem kaynaklarının çoğunu çevrimdışı veya serbest bırakılmış durumda tutmak mümkündür.

• Yalnızca gerektiğinde ikincil bölgede oturum konakları oluşturmak için otomasyonu kullanmak da mümkündür. Bu yöntem maliyetleri iyileştirir, ancak kullandığınız mekanizmaya bağlı olarak daha uzun bir RTO gerektirebilir. Bu yaklaşım yeni bir dağıtım olmadan yük devretme testlerine izin vermez ve belirli kullanıcı grupları için seçmeli yük devretmeye izin vermez.

• İkincil bölgede oturum konaklarının çevrimdışı veya serbest bırakılmış durumda olması, bölge genelinde birincil olağanüstü durum söz konusu olduğunda kapasitenin kullanılabilir olmasını garanti etmez. Ayrıca, gerektiğinde yeni oturum konakları isteğe bağlı olarak ve Site Recovery kullanımıyla dağıtılırsa da geçerlidir. İşlem kapasitesi, yalnızca ilgili kaynaklar zaten ayrılmış ve etkinse garanti edilebilir.

Bulut Önbelleği kullanım senaryoları için yönetilen diskler için Premium katmanını kullanmanızı öneririz.

Depolama

Bu kılavuzda, her Sanal Masaüstü konak havuzu için en az iki ayrı depolama hesabı kullanacaksınız. Biri FSLogix Profili kapsayıcısı, diğeri de Office kapsayıcı verileri içindir. AYRıCA MSIX paketleri için bir depolama hesabına daha ihtiyacınız vardır. Aşağıdaki noktalara dikkat edilmelidir:

• depolama alternatifleri olarak Azure Dosyalar paylaşımını ve Azure NetApp Files'ı kullanabilirsiniz. Seçenekleri karşılaştırmak için bkz . FSLogix kapsayıcı depolama seçenekleri.
• Azure Dosyalar paylaşımı, bölgede kullanılabiliyorsa alanlar arası yedekli depolama (ZRS) dayanıklılığı seçeneğini kullanarak bölge dayanıklılığı sağlayabilir.
• Coğrafi olarak yedekli depolama özelliğini aşağıdaki durumlarda kullanamazsınız:
  • Çifti olmayan bir bölgeye ihtiyacınız vardır. Coğrafi olarak yedekli depolama için bölge çiftleri sabittir ve değiştirilemez.
  • Premium katmanını kullanıyorsunuz.
• RPO ve RTO, FSLogix Bulut Önbelleği mekanizmasına kıyasla daha yüksektir.
• Üretim ortamında yük devretme ve yeniden çalışma test etmek kolay değildir.
• Azure NetApp Files için dikkat edilmesi gereken daha fazla nokta vardır:
  • Bölge yedekliliği henüz kullanılamıyor. Dayanıklılık gereksinimi performanstan daha önemliyse Azure Dosyalar paylaşımını kullanın.
  • Azure NetApp Files bölgesel olabilir; yani müşteriler hangi (tek) Azure Kullanılabilirlik Alanı'nda ayrılacaklarına karar verebilir.
  • Alanlar arası çoğaltma , bölge dayanıklılığı sağlamak için birim düzeyinde oluşturulabilir, ancak çoğaltma zaman uyumsuz gerçekleşir ve el ile yük devretme gerektirir. Bu işlem, sıfırdan büyük bir kurtarma noktası hedefi (RPO) ve kurtarma süresi hedefi (RTO) gerektirir. Bu özelliği kullanmadan önce bölgeler arası çoğaltmayla ilgili gereksinimleri ve dikkat edilmesi gerekenleri gözden geçirin.
  • Ağ dayanıklılığı için kullanabileceğiniz standart ağ özelliği kullanılıyorsa Azure NetApp Files'ı alanlar arası yedekli VPN ve ExpressRoute ağ geçitleriyle kullanabilirsiniz. Daha fazla bilgi için bkz . Desteklenen ağ topolojileri.
  • Azure Sanal WAN, Azure NetApp Files standart ağıyla birlikte kullanıldığında desteklenir. Daha fazla bilgi için bkz . Desteklenen ağ topolojileri.
• Azure NetApp Files'ın bölgeler arası çoğaltma mekanizması vardır. Aşağıdaki noktalar geçerlidir:
  • Tüm bölgelerde kullanılamaz.
  • Azure NetApp Files birimleri bölge çiftlerinin bölgeler arası çoğaltması, Azure Depolama bölge çiftlerinden farklı olabilir.
  • Bölgeler arası çoğaltma ile aynı anda kullanılamaz
  • Yük devretme saydam değildir ve yeniden çalışma için depolamanın yeniden yapılandırılması gerekir.
• Sınır -ları
  • Boyut, saniye başına giriş/çıkış işlemleri (IOPS), hem Azure Dosyalar paylaşımı hem de Azure NetApp Files depolama hesapları ve birimleri için bant genişliği MB/sn'lerinde sınırlar vardır. Gerekirse, FSLogix'teki grup başına ayarları kullanarak Sanal Masaüstü'nde aynı konak havuzu için birden fazla konak kullanmak mümkündür. Ancak, bu yapılandırma daha fazla planlama ve yapılandırma gerektirir.

MSIX uygulama paketleri için kullandığınız depolama hesabı, Profil ve Office kapsayıcıları için diğer hesaplardan farklı olmalıdır. Aşağıdaki Coğrafi olağanüstü durum kurtarma seçenekleri kullanılabilir:

• Birincil bölgede coğrafi olarak yedekli depolamanın etkinleştirildiği bir depolama hesabı
  • İkincil bölge sabittir. Depolama hesabı yük devretmesi varsa bu seçenek yerel erişim için uygun değildir.
• Biri birincil bölgede, diğeri ikincil bölgede (önerilen) iki ayrı depolama hesabı
  • En azından birincil bölge için alanlar arası yedekli depolama kullanın.
  • Her bölgedeki her konak havuzu, düşük gecikme süresiyle MSIX paketlerine yerel depolama erişimine sahiptir.
  • MSIX paketlerini her iki konumda da iki kez kopyalayın ve her iki konak havuzuna da paketleri iki kez kaydedin. Kullanıcıları uygulama gruplarına iki kez atayın.

FSLogix

Microsoft aşağıdaki FSLogix yapılandırmasını ve özelliklerini kullanmanızı önerir:

• Profil kapsayıcısı içeriğinin ayrı BCDR yönetimine sahip olması gerekiyorsa ve Office kapsayıcısına kıyasla farklı gereksinimleri varsa, bunları bölmeniz gerekir.

  • Office Kapsayıcısı yalnızca bir olağanüstü durum olduğunda kaynaktan yeniden oluşturulabilen veya yeniden doldurulabilen önbelleğe alınmış içeriğe sahiptir. Office Kapsayıcısı ile yedeklemeleri tutmanız gerekmeyebilir ve bu da maliyetleri düşürebilir.
  • Farklı depolama hesapları kullanırken yalnızca profil kapsayıcısı üzerinde yedeklemeleri etkinleştirebilirsiniz. Veya saklama süresi, kullanılan depolama alanı, sıklık ve RTO/RPO gibi farklı ayarlarınız olmalıdır.

• Bulut Önbelleği , temel alınan depolama çoğaltma mekanizmalarına bağlı kalmadan birden çok profil depolama konumu belirtebileceğiniz ve profil verilerini zaman uyumsuz olarak çoğaltabileceğiniz bir FSLogix bileşenidir. İlk depolama konumu başarısız olursa veya ulaşılamıyorsa, Cloud Cache otomatik olarak ikincil konumu kullanmak üzere yük devreder ve etkili bir dayanıklılık katmanı ekler. Hem Profil hem de Office kapsayıcılarını birincil ve ikincil bölgelerdeki farklı depolama hesapları arasında çoğaltmak için Bulut Önbelleği'ni kullanın.

  

• Cloud Cache'i oturum ana bilgisayarı VM kayıt defterinde, Profil Kapsayıcısı için bir kez ve Office Kapsayıcısı için bir kez iki kez etkinleştirmeniz gerekir. Office Kapsayıcısı için Bulut Önbelleği'ni etkinleştirmemek mümkündür, ancak etkinleştirilmemesi, yük devretme ve yeniden çalışma olduğunda birincil ve ikincil olağanüstü durum kurtarma bölgesi arasında veri yanlış hizasına neden olabilir. Üretimde kullanmadan önce bu senaryoya dikkatle bakın.

• Bulut Önbelleği hem profil bölme hem de grup başına ayarlarla uyumludur. grup başına, Active Directory gruplarının ve üyeliğinin dikkatli bir şekilde tasarlanması ve planlanması gerekir. Her kullanıcının tam olarak bir grubun parçası olduğundan ve bu grubun konak havuzlarına erişim vermek için kullanıldığından emin olmanız gerekir.

• İkincil olağanüstü durum kurtarma bölgesindeki konak havuzu için kayıt defterinde belirtilen CCDLocations parametresi, birincil bölgedeki ayarlarla karşılaştırıldığında sırayla geri döndürülür. Daha fazla bilgi için bkz . Öğretici: Profil kapsayıcılarını veya office kapsayıcısını birden çok Sağlayıcıya yeniden yönlendirmek için Bulut Önbelleğini Yapılandırma.

  İpucu

  Bu makale belirli bir senaryoya odaklanır. Ek senaryolar FSLogix için yüksek kullanılabilirlik seçenekleri ve FSLogix için İş sürekliliği ve olağanüstü durum kurtarma seçenekleri bölümünde açıklanmıştır.

Aşağıdaki örnekte Bir Bulut Önbelleği yapılandırması ve ilgili kayıt defteri anahtarları gösterilmektedir:

Birincil Bölge = Kuzey Avrupa

• Profil kapsayıcısı depolama hesabı URI'si = \northeustg1\profiles

  • Kayıt Defteri Anahtarı yolu = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profilleri
  • CCDLocations değeri = type=smb,connectionString=\northeustg1\profiles; type=smb,connectionString=\westeustg1\profiles

  Not

  FSLogix Şablonlarını daha önce indirdiyseniz, Active Directory Grup İlkesi Yönetim Konsolu aracılığıyla aynı yapılandırmaları gerçekleştirebilirsiniz. FSLogix için Grup İlkesi Nesnesi'ni ayarlama hakkında daha fazla bilgi için FSLogix Grup İlkesi Şablon Dosyalarını Kullanma kılavuzuna bakın.

  

• Office kapsayıcısı depolama hesabı URI'si = \northeustg2\odcf

  • Kayıt Defteri Anahtarı yolu = HKEY_LOCAL_MACHINE > YAZILIM >İlkesi > FSLogix > ODFC

  • CCDLocations değeri = type=smb,connectionString=\northeustg2\odfc; type=smb,connectionString=\westeustg2\odfc

    

İkincil Bölge = Batı Avrupa

• Profil kapsayıcısı depolama hesabı URI'si = \westeustg1\profiles
  • Kayıt Defteri Anahtarı yolu = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profilleri
  • CCDLocations değeri = type=smb,connectionString=\westeustg1\profiles; type=smb,connectionString=\northeustg1\profiles
• Office kapsayıcısı depolama hesabı URI'si = \westeustg2\odcf
  • Kayıt Defteri Anahtarı yolu = HKEY_LOCAL_MACHINE > YAZILIM >İlkesi > FSLogix > ODFC
  • CCDLocations değeri = type=smb,connectionString=\westeustg2\odfc; type=smb,connectionString=\northeustg2\odfc

Bulut Önbelleği çoğaltması

Bulut Önbelleği yapılandırma ve çoğaltma mekanizmaları, en az veri kaybıyla farklı bölgeler arasında profil verisi çoğaltmasını garanti eder. Aynı kullanıcı profili dosyası tek bir işlem tarafından ReadWrite modunda açılabildiğinden eşzamanlı erişimden kaçınılmalıdır, bu nedenle kullanıcılar aynı anda her iki konak havuzuna da bağlantı açmamalıdır.

Bu mimarinin bir Visio dosyasını indirin.

Veri akışı

1. Sanal Masaüstü kullanıcısı Sanal Masaüstü istemcisini başlatır ve ardından birincil bölge konak havuzuna atanmış yayımlanmış bir Masaüstü veya Uzak Uygulama uygulamasını açar.

2. FSLogix, kullanıcı Profili ve Office kapsayıcılarını alır ve temel alınan depolama VHD/X'i birincil bölgede bulunan depolama hesabından bağlar.

3. Aynı zamanda, Cloud Cache bileşeni birincil bölgedeki dosyalarla ikincil bölgedeki dosyalar arasında çoğaltma başlatır. Bu işlem için birincil bölgedeki Cloud Cache, bu dosyalar üzerinde özel bir okuma-yazma kilidi alır.

4. Aynı Sanal Masaüstü kullanıcısı artık ikincil bölge konak havuzunda atanmış başka bir yayımlanmış uygulamayı başlatmak istiyor.

5. İkincil bölgedeki Sanal Masaüstü oturum konağında çalışan FSLogix bileşeni, yerel depolama hesabından kullanıcı profili VHD/X dosyalarını bağlamaya çalışır. Ancak bu dosyalar birincil bölgedeki Sanal Masaüstü oturum konağından çalışan Cloud Cache bileşeni tarafından kilitlendiğinden bağlama başarısız olur.

6. Varsayılan FSLogix ve Bulut Önbelleği yapılandırmasında, kullanıcı oturum açamaz ve FSLogix tanılama günlüklerinde bir hata izlenir( ERROR_LOCK_VIOLATION 33 (0x21).

   

Kimlik

Sanal Masaüstü için en önemli bağımlılıklardan biri, kullanıcı kimliğinin kullanılabilirliğidir. Oturum konaklarınızdan tam uzak sanal masaüstlerine ve uzak uygulamalara erişmek için kullanıcılarınızın kimlik doğrulaması yapabilmesi gerekir. Microsoft Entra ID , Microsoft'un bu özelliği etkinleştiren merkezi bulut kimliği hizmetidir. Microsoft Entra Id her zaman Sanal Masaüstü için kullanıcıların kimliğini doğrulamak için kullanılır. Oturum konakları, Active Directory Etki Alanı Hizmetleri (AD DS) veya Microsoft Entra Domain Services kullanılarak aynı Microsoft Entra kiracısına veya bir Active Directory etki alanına eklenebilir ve size çeşitli esnek yapılandırma seçenekleri sunar.

• Microsoft Entra ID

  • Yüksek kullanılabilirliğe sahip küresel çok bölgeli ve dayanıklı bir hizmettir. Sanal Masaüstü BCDR planının bir parçası olarak bu bağlamda başka bir eylem gerekmez.

• Active Directory Domain Services

  • Active Directory Etki Alanı Hizmetlerinin dayanıklı ve yüksek oranda kullanılabilir olması için, bölge genelinde bir olağanüstü durum olsa bile birincil Azure bölgesine en az iki etki alanı denetleyicisi (DC) dağıtmanız gerekir. Bu etki alanı denetleyicileri mümkünse farklı kullanılabilirlik alanlarında olmalıdır ve ikincil bölgede ve sonunda şirket içinde altyapıyla doğru çoğaltmayı sağlamanız gerekir. İkincil bölgede genel katalog ve DNS rolleriyle en az bir etki alanı denetleyicisi daha oluşturmanız gerekir. Daha fazla bilgi için bkz. Azure sanal ağında Active Directory Etki Alanı Hizmetleri (AD DS) dağıtma.

• Microsoft Entra Connect

  • Active Directory Etki Alanı Hizmetleri ile Microsoft Entra Id kullanıyorsanız ve ardından Active Directory Etki Alanı Hizmetleri ile Microsoft Entra Id arasında kullanıcı kimliği verilerini eşitlemek için Microsoft Entra Connect kullanıyorsanız, kalıcı bir olağanüstü durumdan korunmak için bu hizmetin dayanıklılığını ve kurtarılmasını göz önünde bulundurmalısınız.

  • İkincil bölgeye hizmetin ikinci bir örneğini yükleyip hazırlama modunu etkinleştirerek yüksek kullanılabilirlik ve olağanüstü durum kurtarma sağlayabilirsiniz.

  • Kurtarma varsa, yöneticinin ikincil örneği hazırlama modundan çıkararak yükseltmesi gerekir. Bir sunucuyu hazırlama moduna yerleştirmekle aynı yordamı izlemeleri gerekir. Bu yapılandırmayı gerçekleştirmek için Microsoft Entra Genel Yönetici kimlik bilgileri gereklidir.

    

• Microsoft Entra Domain Services

  • Microsoft Entra Domain Services'i bazı senaryolarda Active Directory Etki Alanı Hizmetlerine alternatif olarak kullanabilirsiniz.
  • Yüksek kullanılabilirlik sunar.
  • Coğrafi olağanüstü durum kurtarma senaryonuzun kapsamındaysa, çoğaltma kümesi kullanarak ikincil Azure bölgesine başka bir çoğaltma dağıtmanız gerekir. Bu özelliği birincil bölgede yüksek kullanılabilirliği artırmak için de kullanabilirsiniz.

Mimari diyagramları

Kişisel konak havuzu

Bu mimarinin bir Visio dosyasını indirin.

Havuza alınan konak havuzu

Bu mimarinin bir Visio dosyasını indirin.

Yük devretme ve yeniden çalışma

Kişisel konak havuzu senaryosu

Profil ve Office kapsayıcıları için bulut önbelleği ve dış depolama alanı kullanılmadığından kişisel konak havuzu için yük devretme ve yeniden çalışma farklıdır. Verileri oturum konağından bir kapsayıcıya kaydetmek için FSLogix teknolojisini kullanmaya devam edebilirsiniz. Olağanüstü durum kurtarma bölgesinde ikincil konak havuzu olmadığından çoğaltmak ve hizalamak için daha fazla çalışma alanı ve Sanal Masaüstü kaynağı oluşturmanız gerekmez. Oturum ana bilgisayar VM'lerini çoğaltmak için Site Recovery'yi kullanabilirsiniz.

Site Recovery'i birkaç farklı senaryoda kullanabilirsiniz. Sanal Masaüstü için Azure Site Recovery'de Azure'da Azure'da olağanüstü durum kurtarma mimarisini kullanın.

Aşağıdaki önemli noktalar ve öneriler geçerlidir:

• Site Recovery yük devretmesi otomatik değildir; yöneticinin Azure portalını veya PowerShell/API'yi kullanarak tetiklemesi gerekir.
• PowerShell kullanarak Site Recovery yapılandırmasının ve işlemlerinin tamamını betik oluşturabilir ve otomatikleştirebilirsiniz.
• Site Recovery,hizmet düzeyi sözleşmesi (SLA) içinde bildirilen bir RTO'ya sahiptir. Çoğu zaman, Site Recovery vm'lerin yükünü dakikalar içinde devredebilir.
• Site Recovery'i Azure Backup ile kullanabilirsiniz. Daha fazla bilgi için bkz . Azure Backup ile Site Recovery kullanma desteği.
• Sanal Masaüstü portalı deneyiminde doğrudan tümleştirme olmadığından Site Recovery'yi VM düzeyinde etkinleştirmeniz gerekir. Ayrıca tek VM düzeyinde yük devretme ve yeniden çalışma tetiklemeniz gerekir.
• Site Recovery, genel Azure VM'leri için ayrı bir alt ağda yük devretme testi özelliği sağlar. Aynı anda hizmet denetim düzlemini çağıran iki özdeş Sanal Masaüstü oturum konağından bu özelliği Sanal Masaüstü VM'leri için kullanmayın.
• Site Recovery, çoğaltma sırasında Sanal Makine uzantılarını korumaz. Sanal Masaüstü oturumu ana bilgisayar VM'leri için herhangi bir özel uzantıyı etkinleştirirseniz, yük devretme veya yeniden çalışma sonrasında uzantıları yeniden etkinleştirmelisiniz. Joindomain ve Microsoft.PowerShell.DSC Sanal Masaüstü yerleşik uzantıları yalnızca bir oturum konağı VM oluşturulduğunda kullanılır. İlk yük devretmeden sonra onları kaybetmek güvenlidir.
• Azure bölgeleri arasında Azure VM olağanüstü durum kurtarma için Destek matrisini gözden geçirmeyi ve Site Recovery Azure-Azure olağanüstü durum kurtarma senaryosunun gereksinimleri, sınırlamalarını ve uyumluluk matrisini, özellikle de desteklenen işletim sistemi sürümlerini denetlemeyi unutmayın.
• Vm'nin yükünü bir bölgeden diğerine devreddiğinizde, VM korumasız bir durumda hedef olağanüstü durum kurtarma bölgesinde başlatılır. Yeniden çalışma mümkündür, ancak kullanıcının ikincil bölgedeki VM'leri yeniden koruması ve ardından birincil bölgeye çoğaltmayı etkinleştirmesi gerekir.
• Yük devretme ve yeniden çalışma yordamlarının düzenli testlerini yürütür. Ardından, belirli Sanal Masaüstü ortamınıza göre adımların ve kurtarma eylemlerinin tam listesini belgeleyin.

Havuza alınan konak havuzu senaryosu

Etkin-etkin olağanüstü durum kurtarma modelinin istenen özelliklerinden biri, kesinti olması durumunda hizmeti kurtarmak için yönetici müdahalesinin gerekli olmamasıdır. Yük devretme yordamları yalnızca etkin-pasif mimaride gerekli olmalıdır.

Etkin-pasif modelde ikincil olağanüstü durum kurtarma bölgesi, en az kaynak yapılandırılmış ve etkin olarak boşta olmalıdır. Yapılandırma birincil bölgeyle uyumlu tutulmalıdır. Yük devretme varsa, ikincil olağanüstü durum kurtarma konak havuzundaki uzak uygulamalar için tüm kullanıcılar için tüm masaüstü ve uygulama gruplarına yeniden atamalar aynı anda gerçekleşir.

Etkin-etkin bir modele ve kısmi yük devretmeye sahip olmak mümkündür. Konak havuzu yalnızca masaüstü ve uygulama grupları sağlamak için kullanılıyorsa, kullanıcıları birden çok örtüşmeyen Active Directory grubuna bölümleyebilir ve grubu birincil veya ikincil olağanüstü durum kurtarma konak havuzlarında masaüstü ve uygulama gruplarına yeniden atayabilirsiniz. Kullanıcının aynı anda her iki konak havuzuna da erişimi olmamalıdır. Birden çok uygulama grubu ve uygulama varsa, kullanıcıları atamak için kullandığınız kullanıcı grupları çakışabilir. Bu durumda, etkin-etkin bir strateji uygulamak zordur. Bir kullanıcı birincil konak havuzunda uzak bir uygulama başlattığında, kullanıcı profili bir oturum ana bilgisayarı VM'sine FSLogix tarafından yüklenir. İkincil konak havuzunda da aynı işlemi yapmaya çalışmak, temel alınan profil diskinde çakışmaya neden olabilir.

İlk durum ve yapılandırma varsayımları şunlardır:

• Birincil bölgedeki ve ikincil olağanüstü durum kurtarma bölgelerindeki konak havuzları, Bulut Önbelleği de dahil olmak üzere yapılandırma sırasında hizalanır.
• Konak havuzlarında hem DAG1 masaüstü hem de APPG2 ve APPG3 uzak uygulama uygulama grupları kullanıcılara sunulur.
• Birincil bölgedeki konak havuzunda, KULLANıCıLARı DAG1, APPG2 ve APPG3'e atamak için Active Directory kullanıcı grupları GRP1, GRP2 ve GRP3 kullanılır. Bu grupların kullanıcı üyelikleri çakışıyor olabilir, ancak buradaki model tam yük devretme ile etkin-pasif kullandığından, bu bir sorun değildir.

Aşağıdaki adımlar, planlı veya plansız olağanüstü durum kurtarma işleminden sonra yük devretmenin ne zaman gerçekleştiğini açıklar.

1. Birincil konak havuzunda, DAG1, APPG2 ve APPG3 uygulama grupları için GRP1, GRP2 ve GRP3 gruplarına göre kullanıcı atamalarını kaldırın.
2. Birincil konak havuzundan tüm bağlı kullanıcılar için zorlamalı bir bağlantı kesiliyor.
3. Aynı uygulama gruplarının yapılandırıldığı ikincil konak havuzunda, GRP1, GRP2 ve GRP3 gruplarını kullanarak DAG1, APPG2 ve APPG3'e kullanıcı erişimi vermelisiniz.
4. İkincil bölgedeki konak havuzunun kapasitesini gözden geçirin ve ayarlayın. Burada oturum konaklarını otomatik olarak açmak için otomatik ölçeklendirme planına güvenmek isteyebilirsiniz. Gerekli kaynakları el ile de başlatabilirsiniz.

Yeniden çalışma adımları ve akışı benzerdir ve işlemin tamamını birden çok kez yürütebilirsiniz. Bulut Önbelleği ve depolama hesaplarının yapılandırılması, Profil ve Office kapsayıcı verilerinin çoğaltılmasını sağlar. Yeniden çalışmadan önce konak havuzu yapılandırmasının ve işlem kaynaklarının kurtarıldığından emin olun. Depolama bölümünde, birincil bölgede veri kaybı varsa, Bulut Önbelleği profil ve Office kapsayıcı verilerini ikincil bölge depolama alanından çoğaltır.

Üretim ortamını etkilemeden birkaç yapılandırma değişikliğiyle bir yük devretme testi planı uygulamak da mümkündür.

• Üretim için Active Directory'de birkaç yeni kullanıcı hesabı oluşturun.
• GRP-TEST adlı yeni bir Active Directory grubu oluşturun ve kullanıcıları atayın.
• GRP-TEST grubunu kullanarak DAG1, APPG2 ve APPG3'e erişim atayın.
• Uygulamaları test etmek için GRP-TEST grubundaki kullanıcılara yönergeler verin.
• Birincil konak havuzundan erişimi kaldırmak ve ikincil olağanüstü durum kurtarma havuzuna erişim vermek için GRP-TEST grubunu kullanarak yük devretme yordamını test edin.

Önemli öneriler:

• PowerShell, Azure CLI veya başka bir kullanılabilir API veya aracı kullanarak yük devretme işlemini otomatikleştirin.
• Yük devretme ve yeniden çalışma yordamının tamamını düzenli aralıklarla test edin.
• Birincil ve ikincil olağanüstü durum bölgesindeki konak havuzlarının eşitlenmiş olduğundan emin olmak için düzenli bir yapılandırma hizalama denetimi gerçekleştirin.

Yedekleme

Bu kılavuzda profil kapsayıcıları ile Office kapsayıcıları arasında profil bölme ve veri ayrımı olduğu varsayımı yer alır. FSLogix, bu yapılandırmaya ve ayrı depolama hesaplarının kullanımına izin verir. Ayrı depolama hesaplarına girdikten sonra farklı yedekleme ilkeleri kullanabilirsiniz.

• ODFC Kapsayıcısı için, içerik yalnızca Microsoft 365 gibi çevrimiçi veri deposundan yeniden oluşturulabilen önbelleğe alınmış verileri temsil ediyorsa, verileri yedeklemek gerekmez.

• Office kapsayıcı verilerini yedeklemek gerekiyorsa, daha düşük maliyetli bir depolama alanı veya farklı bir yedekleme sıklığı ve saklama süresi kullanabilirsiniz.

• Kişisel bir konak havuzu türü için, yedeklemeyi oturum ana bilgisayarı VM düzeyinde yürütmeniz gerekir. Bu yöntem yalnızca veriler yerel olarak depolanıyorsa geçerlidir.

• OneDrive ve bilinen klasör yeniden yönlendirmesi kullanıyorsanız, kapsayıcının içine veri kaydetme gereksinimi kaybolabilir.

  Not

  OneDrive yedeklemesi bu makalede ve senaryoda dikkate alınmaz.

• Başka bir gereksinim yoksa, birincil bölgedeki depolama için yedekleme yeterli olmalıdır. Olağanüstü durum kurtarma ortamının yedeği normalde kullanılmaz.

• Azure Dosyalar paylaşımı için Azure Backup'ı kullanın.

  • Kasa dayanıklılığı türü için, site dışında veya bölge yedekleme depolaması gerekmiyorsa alanlar arası yedekli depolama kullanın. Bu yedeklemeler gerekiyorsa coğrafi olarak yedekli depolama kullanın.

• Azure NetApp Files kendi yerleşik yedekleme çözümünü sağlar.

  • Gereksinimler ve sınırlamalarla birlikte bölge özelliği kullanılabilirliğini de denetlediğinizden emin olun.

• Uygulama paketleri depoları kolayca yeniden oluşturulamıyorsa, MSIX için kullanılan ayrı depolama hesapları da bir yedekleme kapsamında olmalıdır.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazarlar:

• Ben Martin Baur | Bulut Çözümü Mimarı
• Igor Pagliai | Azure için FastTrack (FTA) Baş Mühendisi

Diğer katkıda bulunanlar:

• Nelson Del Villar | Bulut Çözümü Mimarı, Azure Core Altyapısı
• Jason Martinez | Teknik Yazar

Sonraki adımlar

• Sanal Masaüstü olağanüstü durum kurtarma planı
• Sanal Masaüstü için BCDR - Bulut Benimseme Çerçevesi
• Dayanıklılık ve kullanılabilirlik oluşturmak için Bulut Önbelleği

İlgili kaynaklar

• Güvenilir Azure uygulamaları tasarlama
• Şirket içinde erişilen ve AD DS ile güvenliği sağlanan Azure dosyaları
• Kuruluş için Sanal Masaüstü
• Olağanüstü durum kurtarma ile kurumsal dosya paylaşımları
• FSLogix yapılandırma örnekleri