Azure Site Recovery kullanarak kapasite planlaması
Bir kuruluş olarak, planlı ve plansız kesintiler sırasında verilerinizin güvenliğini, uygulamalarınızı ve iş yüklerinizi çevrimiçi ortamda tutan bir iş sürekliliği ve olağanüstü durum kurtarma (BCDR) stratejisi benimsemek zorunludur.
Azure Stack Hub'da Azure Site Recovery, sanal makine (VM) iş yüklerinin birincil siteden ikincil bir konuma çoğaltılarak, kesintiler sırasında kuruluş verilerinin, uygulama kullanılabilirliğinin ve iş yüklerinin güvenliğini destekleyebilecek hizmetler sağlar. Örneğin, birincil sitenizde bir kesinti oluştuğunda uygulamalarınıza erişmek için ikincil bir konuma yük devredersiniz. Birincil site yeniden çalışır duruma gelir gelmez yeniden çalıştırabilirsiniz. Daha fazla bilgi için bkz. Site Recovery hakkında.
VM'lerin iki Azure Stack Hub damgaları arasında çoğaltılabilmesi için iki ortam yapılandırabilirsiniz:
- Kaynak ortam:
- Kiracı VM'lerin çalıştığı Azure Stack Hub damgası.
- Hedef ortam:
- Azure Site Recovery Kaynak Sağlayıcısının çalıştığı yer.
İş sürekliliği ve olağanüstü durum kurtarma planının başarısı için önemli bir bileşen kapasite planlamasıdır. Kapasite planlaması sırasında dikkate alınması gereken birkaç faktör vardır:
Korumak istediğiniz belirli iş yükleri için kurtarma süresi hedefleri (RTO) ve kurtarma noktası hedefleri (RPO).
İş yükleri ve uygulama özellikleri:
- İlgili VM'de verilerin değişme sıklıkları.
- Ne kadar veri oluşturulur veya kaldırılır?
- Uygulama tasarımı nasıl görünüyor ve daha fazlası?
VM boyutları, disk sayısı ve her vm'nin diğer VM'lere nasıl bağlandığı.
- Birkaç VM gerektiren çözümler için bu VM'lerin hangi sırayla başlatılması gerektiğini anlayın.
Kaynak ve hedef ortamlar arasındaki ağ bant genişliği. Bu bileşen, RPC'leri etkileyebilir.
Bu noktaların her biri önemlidir ve BCDR planı oluştururken geniş kapsamlı etkilere sahiptir.
Aşağıdaki bölümlerde Azure Site Recovery perspektifinden dikkate alınması gereken ana noktalar listelanmaktadır. Her BCDR planı farklıdır ve korumayı planladığınız iş yüklerinin özelliklerine dayanır. Bu nedenle, bu liste kapsamlı değildir.
Kaynakla ilgili dikkat edilmesi gerekenler
Kaynak ortamda Azure Stack Hub, Azure Site Recovery VM aletini çalıştırır. VM, Azure Stack Hub kullanıcı aboneliğinde çalışan bir Standard_DS4_v2 (8 vCPU, 28 Gb bellek, 32 veri diski) vm'dir.
Kaynak ortamda aşağıdaki alanları göz önünde bulundurun:
Kota:
- Azure Site Recovery VM aletini oluşturmak için yeterli kotaya sahip olmanız gerekir. Genel plana bağlı olarak bir veya daha fazla gerekir.
Azure Site Recovery VM gereci için depolama:
Azure Site Recovery VM gereci, VM boyutuna göre tanımlanan veri gereksinimlerine sahiptir.
Kapasite planlaması yaparken alet VM'sinin yeniden çalışma ve yeniden koruma mekanizmalarını kullanmak için yeterli depolama alanına sahip olduğundan emin olun.
Not
Depolama sınırlamaları varsa, yeniden çalışma ve yeniden koruma bir iç hata oluştu iletisiyle başarısız olabilir. Kullanıcılar gerçek Azure Resource Manager hatasını onaylamak için alet üzerindeki olay günlüklerini denetlemelidir. Daha fazla bilgi için bkz. Azure Site Recovery için bilinen sorunlar.
Bant genişliği:
- İlk çoğaltma yüksek bant genişliği kullanımı oluşturur.
- Her VM'de yapılan değişiklikler, çoğaltma ilkelerine ve her uygulama türüne bağlı olarak çoğaltılır.
Hedefle ilgili dikkat edilmesi gerekenler
Hedef ortamda kapasite planlaması için dikkate alınması gereken iki parça vardır:
Azure Site Recovery hizmet gereksinimleri: Azure Site Recovery çalıştırmak için iş yüklerini korumadan ne kadar tüketilir?
Korunan iş yükleri gereksinimleri.
Hedef ortam, VM'leri kaynaktan (kasa başına bir alet) korumak için her Site Recovery gereci için bir Azure Site Recovery kasası oluşturulmasını gerektirir. Bu, kapasite açısından bir sınırlama olmasa da, genel ortamın tasarımı planlandığında dikkate alınmalıdır.
Azure Site Recovery RP kaynakları
Azure Stack Hub'a Azure Site Recovery yüklemesi için Site Recovery Kaynak Sağlayıcısı'nı (RP) yüklemeniz gerekir.
Not
Microsoft.SiteRecovery-1.2301.2216.2287 ile Azure Stack Hub'da Azure Site Recovery bağımlılık olarak Event Hubs gerektirmez.
Bu hizmet Azure Stack Hub yönetici aboneliğinde oluşturulur ve Azure Stack Hub tarafından yönetilir, bu nedenle yapılandırma gerekmez. Ancak, tüm hizmetlerde olduğu gibi bu kaynaklar da bellek, depolama alanı kullanır ve belirli vCPU'lar ayrılır:
| Hizmet | Sanal Çekirdek | Bellek | Disk Boyutu |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
Not
Bu kaynaklar, Azure Stack Hub'ın yönetim tarafındaki Azure Stack Hub hizmetleridir. Yüklendikten sonra platform bu kaynakları yönetir.
Korunan iş yükleri
BCDR planını oluştururken korunan iş yüklerinin tüm yönlerini göz önünde bulundurun. Aşağıdaki liste tamamlanmaz ve başlangıç noktası olarak kabul edilmelidir:
VM boyutu, disk sayısı, disk boyutu, IOPS, veri değişim sıklığı ve oluşturulan yeni veriler.
Ağ bant genişliğiyle ilgili dikkat edilmesi gerekenler:
- Değişiklik çoğaltması için gereken ağ bant genişliği.
- Hedef ortamda azure Site Recovery kaynak ortamdan alabildiği aktarım hızı miktarı.
- Bir kerede toplu iş için vm sayısı. Bu sayı, belirli bir süre içinde ilk çoğaltmayı tamamlamak için tahmini bant genişliğine dayanır.
- Belirli bir bant genişliği için elde edilebilen RPO.
- Daha düşük bant genişliği sağlanırsa istenen RPO üzerindeki etki.
Depolama konusunda dikkat edilmesi gerekenler:
- İlk çoğaltma için gereken veri miktarı.
- Bu aralıklarda, korunan her VM için kaç kurtarma noktasının tutulduğu ve verilerin nasıl arttığı.
- Kullanıcıların yeterli ayırmaya sahip olması için hedef Azure Stack Hub kullanıcı aboneliklerine kaç kota atanması gerektiği.
- Çoğaltma için önbellek depolama hesabı.
İşlemle ilgili dikkat edilmesi gerekenler:
- Yük devretme gerçekleştiğinde VM'ler hedef Azure Stack Hub kullanıcı aboneliklerinde başlatılır. Bu VM kaynaklarını başlatabilmek için yeterli kota ayırma işlemi gerçekleştirilmelidir.
- VM'nin korunması sırasında, korumalı VM kaynak ortamda etkin olduğunda, hedef ortamda vCPU, bellek vb. gibi VM ile ilgili kaynaklar tüketılmaz. Bu kaynaklar yalnızca yük devretme testi gibi bir yük devretme işlemi sırasında uygun hale gelir.
Azure Stack Hub'da Azure Site Recovery kapsamı için, özellikle kullanılan önbellek depolama hesabı için hesaplamalar için bir başlangıç noktası aşağıdadır:
Yük devretme varsa, normal işlemler sırasında çoğaltılan disk sayısını ortalama RPO ile çarpın. Örneğin, sahip olabilirsiniz (2 MB * 250s). Önbellek depolama hesabı normalde disk başına birkaç KB ile 500 MB arasıdır.
En kötü durum senaryosuna göre yük devretme varsa, bir gün içinde ortalama RPO ile çoğaltılan disk sayısını çarpın.
Önemli
Azure Site Recovery bazı bölümleri çalışmıyorsa ancak diğerleri çalışıyorsa, Azure Site Recovery zaman aşımına uğramaya karar vermeden önce depolama hesabında en fazla bir günlük kayıt olabilir.
Yeni VM'ye yeniden çalışma. Her toplu iş için disk boyutunun toplamını hesaplayın.
- Hedef boş bir disk olduğundan hedef VM'nin uygulanabilmesi için diskin tamamının önbellek depolama hesabına kopyalanması gerekir.
- İlişkili veriler kopyalandıktan sonra silinir, ancak tüm disk boyutlarının toplamıyla en yüksek kullanımı görme olasılığı yüksektir.
Korumaya çalıştığınız çözümün özelliklerine göre BDCR planını oluşturun.
Aşağıdaki tablo, ortamlarımızda çalıştırılacak testlerin bir örneğidir. Kendi uygulamanız için bir temel almak için bu içgörüden yararlanabilirsiniz, ancak her iş yükü farklılık gösterir:
Yapılandırma
| Blok boyutu | Aktarım hızı/disk |
|---|---|
| 2 MB | 2 MB/sn |
| 64 KB | 2 MB/sn |
| 8 KB | 1 MB/sn |
| 8 KB | 2 MB/sn |
Sonuç
| Desteklenen disk sayısı | Toplam aktarım hızı | Toplam OPS | Darboğaz |
|---|---|---|---|
| 68 | 136 MB/sn | 68 | depolama |
| 60 | 120 MB/sn | 2048 | depolama |
| 28 | 28 MB/sn | 3584 | Azure Site Recovery CPU ve bellek |
| 16 | 32 MB/sn | 4096 |
Not
8 KB, Azure Site Recovery'ın desteklediği en küçük blok boyutudur. 8 KB'tan küçük değişiklikler 8 KB olarak değerlendirilir.
Daha fazla test etmek için tutarlı bir iş yükü türü oluşturduk; Örneğin, 8 Kb'lık bloklarda disk başına toplam 1 MB/sn'ye kadar tutarlı depolama değişiklikleri. Değişikliklerin günün çeşitli saatlerinde veya çeşitli boyutlarda ani artışlarla gerçekleşebileceği göz önüne alındığında, bu senaryo büyük olasılıkla gerçek bir iş yükünde değildir.
Bu rastgele desenleri çoğaltmak için senaryoları aşağıdakilerle de test ettik:
- Aynı Azure Site Recovery VM aletiyle korunan 120 VM (80 Windows, 40 Linux).
Rastgele aralıklarla( saatte en az iki kez) oluşturulan her VM, beş dosyada toplam 5 Gb veriyi engeller.
Azure Site Recovery hizmetlerinde düşük-orta yüke sahip tüm 120 VM'de çoğaltma başarılı oldu.
Not
Bu sayılar yalnızca taban çizgisi olarak kullanılmalıdır. Doğrusal olarak ölçeklendirilmeleri gerekmez. Aynı sayıda VM'den oluşan başka bir toplu iş eklenmesi ilk toplu işlemden daha az etkilenebilir. Sonuçlar, kullanılan iş yüklerinin türüne yüksek oranda bağlıdır.
Nasıl planlamalı ve test etmelisiniz?
Uygulamaların ve çözüm iş yüklerinin belirli kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) gereksinimleri vardır. Etkili iş sürekliliği ve olağanüstü durum kurtarma (BCDR) tasarımı, çözüme özgü mekanizmaları kullandığımız için bu gereksinimleri karşılayan platform düzeyindeki özelliklerden yararlanır. BCDR özelliklerini tasarlamak için platform olağanüstü durum kurtarma (DR) gereksinimlerini yakalayın ve tasarımınızdaki tüm bu faktörleri göz önünde bulundurun:
Uygulama ve veri kullanılabilirliği gereksinimleri:
- Her iş yükü için RTO ve RPO gereksinimleri.
- Etkin-aktif ve aktif-pasif kullanılabilirlik desenleri için destek.
Performans için bileşen yakınlığı ile yük devretme için çok bölgeli dağıtım desteği. Kesinti sırasında düşük işlevsellik veya düşük performans ile uygulama işlemleriyle karşılaşabilirsiniz.
Not
Uygulama üzerinde yerel olarak çalıştırıldığını biliyor olabilir veya birden çok Azure Stack Hub ortamı arasında çalıştırabilen belirli bileşenlere sahip olabilir. Bu durumda, azure Site Recovery kullanarak yalnızca bu işlevselliğe sahip olmayan bileşenlere sahip VM'leri çoğaltabilirsiniz; örneğin, ön uçları Azure Stack Hub ortamlarına dağıtabileceğiniz bir ön uç veya arka uç türü çözümü.
Üretim ve DR ağlarında çakışan IP adresi aralıklarını kullanmaktan kaçının.
- Çakışan IP adreslerine sahip üretim ve DR ağları, uygulama yük devretmesini karmaşıklaştırabilen ve geciktirebilen bir yük devretme işlemi gerektirir. Mümkün olduğunda, tüm sitelere eş zamanlı bağlantı sağlayan bir BCDR ağ mimarisi planlayın.
Hedef ortamlarınızı boyutlandırma:
- Kaynağı ve hedefi 1:1 olarak kullanıyorsanız, hedef ortamınızda biraz daha fazla depolama alanı ayırın. Bunun nedeni disk yer işaretlerinin geçmişinin gerçekleşmesidir. Bu ayırma, yalnızca verilerde yapılan değişiklikleri içerdiğinden 2 kat artış değildir. Verilerin türüne ve beklenen değişikliklere bağlı olarak ve hedefte 1,5x ile 2 kat daha fazla depolama alanı olan çoğaltma ilkeleri, yük devretme işlemlerinin sorun oluşturmamasını sağlar.
- Hedef Azure Stack Hub ortamını birden çok Azure Stack Hub kaynağı için hedef olarak kullanmayı düşünebilirsiniz. Bu durumda genel maliyeti düşürebilirsiniz ancak belirli iş yükleri az olduğunda ne olacağını planlamanız gerekir; örneğin, hangi kaynağın önceliğe sahip olması gerektiği.
- Hedef ortamınız diğer iş yüklerini çalıştırmak için kullanılıyorsa BCDR planı bu iş yüklerinin davranışını içermelidir. Örneğin, geliştirme/test VM'lerini hedef ortamda çalıştırabilir ve kaynak ortamınızda bir sorun oluşursa, korumalı VM'leri başlatmak için yeterli kaynağın kullanılabilir olduğundan emin olmak için hedef üzerindeki tüm VM'leri kapatabilirsiniz.
BCDR'yi test etmeli ve düzenli olarak doğrulamalısınız. Bunu yapmak için yük devretme test işlemlerini kullanabilir veya iş yüklerinin tamamını taşıyarak akışları uçtan uca doğrulayabilirsiniz.
Sonraki adımlar
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin