Azure'da görev açısından kritik iş yükleri için tasarım metodolojisi
Herhangi bir bulut platformunda görev açısından kritik bir uygulama oluşturmak için özellikle şu karmaşıklıklar söz konusu olduğundan önemli teknik uzmanlık ve mühendislik yatırımı gerekir:
- Bulut platformunu anlama,
- Doğru hizmetleri ve bileşimi seçme,
- Doğru hizmet yapılandırmasını uygulama,
- Kullanılan hizmetleri kullanıma hazır hale getirme ve
- En son en iyi uygulamalar ve hizmet yol haritaları ile sürekli uyumlu hale getirme.
Bu tasarım metodolojisi, bu karmaşıklıkta gezinmeye ve en uygun hedef mimariyi oluşturmak için gereken tasarım kararlarını bilgilendirmeye yardımcı olacak kolay bir tasarım yolu sağlamaya çalışır.
1—İş gereksinimleri için tasarım
Görev açısından kritik iş yüklerinin tümü aynı gereksinimlere sahip değildir. Bu tasarım metodolojisi tarafından sağlanan gözden geçirme konularının ve tasarım önerilerinin farklı uygulama senaryoları için farklı tasarım kararları ve dezavantajları getireceğini tahmin edin.
Güvenilirlik katmanı seçme
Güvenilirlik göreli bir kavramdır ve herhangi bir iş yükünün uygun şekilde güvenilir olması için onu çevreleyen iş gereksinimlerini yansıtması gerekir. Örneğin, %99,999 kullanılabilirlik Hizmet Düzeyi Hedefi 'ne (SLO) sahip görev açısından kritik bir iş yükü, %99,9 SLO'ya sahip daha az kritik bir iş yükünden çok daha yüksek güvenilirlik düzeyi gerektirir.
Bu tasarım metodolojisi, gerekli güvenilirlik özelliklerini bilgilendirmek için kullanılabilirlik SLO'ları olarak ifade edilen güvenilirlik katmanları kavramını uygular. Aşağıdaki tabloda, ortak güvenilirlik katmanlarıyla ilişkili izin verilen hata bütçeleri yakalanıyor.
| Güvenilirlik Katmanı (Kullanılabilirlik SLO'su) | İzin Verilen Kapalı Kalma Süresi (Hafta) | İzin Verilen Kapalı Kalma Süresi (Ay) | İzin Verilen Kapalı Kalma Süresi (Yıl) |
|---|---|---|---|
| %99,9 | 10 dakika, 4 saniye | 43 dakika, 49 saniye | 8 saat, 45 dakika, 56 saniye |
| %99,95 | 5 dakika, 2 saniye | 21 dakika, 54 saniye | 4 saat, 22 dakika, 58 saniye |
| %99,99 | 1 dakika | 4 dakika 22 saniye | 52 dakika, 35 saniye |
| %99,999 | 6 saniye | 26 saniye | 5 dakika, 15 saniye |
| 99.9999% | <1 saniye | 2 saniye | 31 saniye |
Önemli
Kullanılabilirlik SLO'sunun bu tasarım metodolojisi tarafından basit çalışma süresinden daha fazla olduğu, bunun yerine bilinen iyi durumdaki bir uygulama durumuna göre tutarlı bir uygulama hizmeti düzeyi olduğu kabul edilir.
İlk alıştırma olarak okuyucuların ne kadar kapalı kalma süresinin kabul edilebilir olduğunu belirleyerek bir hedef güvenilirlik katmanı seçmeleri tavsiye edilir. Belirli bir güvenilirlik katmanının takip edilerek tasarım yolu ve kapsanan tasarım kararları önemli ölçüde önemli ölçüde etkilenecek ve bu da farklı bir hedef mimariyle sonuçlanacaktır.
Bu görüntüde, farklı güvenilirlik katmanlarının ve temel alınan iş gereksinimlerinin kavramsal başvuru uygulaması için hedef mimariyi nasıl etkilediği, özellikle bölgesel dağıtım sayısı ve kullanılan küresel teknolojilerle ilgili olduğu gösterilmektedir.
Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO), gerekli güvenilirliği belirlerken daha kritik öneme sahiptir. Örneğin, bir dakikadan kısa bir uygulama RTO'sunun elde edilmesi için çabalıyorsanız yedekleme tabanlı kurtarma stratejileri veya etkin-pasif dağıtım stratejisi büyük olasılıkla yetersizdir.
2—Tasarım ilkelerini kullanarak tasarım alanlarını değerlendirme
Bu metodolojinin temelinde aşağıdakilerden oluşan kritik bir tasarım yolu yer alır:
- Temel tasarım ilkeleri
- Ağırlıklı olarak birbiriyle ilişkili ve bağımlı tasarım kararlarıyla temel tasarım alanı .
Her tasarım alanında alınan kararların etkisi, diğer tasarım alanları ve tasarım kararları arasında yankılanacaktır. İlgili tasarım alanlarında denge sağlayabilecek kapsamış kararların sonuçlarını daha iyi anlamak için sağlanan önemli noktaları ve önerileri gözden geçirin.
Örneğin, bir hedef mimari tanımlamak için önemli bileşenler arasında uygulama durumunun en iyi nasıl izleneceğini belirlemek kritik önem taşır. Kararların alınmasına yardımcı olmak için ana hatlarıyla verilen önerileri kullanarak sistem durumu modelleme tasarım alanını gözden geçirmenizi kesinlikle öneririz.
3—görev açısından kritik ilk uygulamanızı dağıtma
Bu metodolojiye dayalı tasarım kararlarını açıklayan bu başvuru mimarilerine bakın.
İpucu
Mimari, tasarım önerilerini gösteren Görev Açısından Kritik Çevrimiçi uygulama tarafından desteklenir.
Üretim sınıfı yapıtlar Her teknik yapıt, tüm uçtan uca operasyonel yönleri dikkate alındığında üretim ortamlarında kullanıma hazırdır.
Gerçek dünya deneyimlerinde kökenli Tüm teknik kararlar, Azure müşterilerinin deneyimleri ve bu çözümlerin dağıtılmasından alınan dersler tarafından yönlendirilir.
Azure yol haritası hizalaması Görev açısından kritik başvuru mimarilerinin, Azure ürün yol haritalarıyla uyumlu kendi yol haritaları vardır.
4—İş yükünüzü Azure giriş bölgelerine tümleştirme
Azure giriş bölgesi abonelikleri , merkezi idare gerektiren kurumsal dağıtımlar için paylaşılan altyapı sağlar.
Görev açısından kritik uygulamanız için hangi bağlantı kullanım örneğinin gerekli olduğunu değerlendirmek çok önemlidir. Azure giriş bölgeleri, farklı Yönetim Grubu kapsamlarına ayrılmış iki ana arketipi destekler: Bu görüntüde gösterildiği gibi Çevrimiçi veya Şirket .
Çevrimiçi abonelik
Görev açısından kritik bir iş yükü, Azure giriş bölgesi mimarisinin geri kalanına doğrudan kurumsal ağ bağlantısı olmadan bağımsız bir çözüm olarak çalışır. Uygulama, ilke temelli idare aracılığıyla daha fazla korunacak ve ilke aracılığıyla merkezi platform günlüğüyle otomatik olarak tümleştirilecektir.
Temel mimari ve Görev Açısından Kritik Çevrimiçi uygulama, Çevrimiçi yaklaşımla uyumlu.
Corp. aboneliği
Bir Corp. aboneliğine dağıtıldığında görev açısından kritik bir iş yükü, bağlantı kaynaklarını sağlamak için Azure giriş bölgesine bağlıdır. Bu yaklaşım, diğer uygulamalar ve paylaşılan hizmetlerle tümleştirmeye olanak tanır. Paylaşılan hizmet platformunun bir parçası olarak önceden mevcut olacak bazı temel kaynakları tasarlamanız gerekir. Örneğin, bölgesel dağıtım damgası artık kısa ömürlü bir Sanal Ağ veya Azure Özel DNS Bölgesi'ni kapsamamalıdır çünkü bunlar Corp. aboneliğinde yer alacaktır.
Bu kullanım örneğini kullanmaya başlamak için Azure giriş bölgesi başvuru mimarisinde temel mimariyi öneririz.
İpucu
Önceki mimari, Görev Açısından Kritik Bağlı uygulama tarafından yedeklenmiştir.
5—Korumalı alan uygulama ortamı dağıtma
Tasarım etkinliklerine paralel olarak, Mission-Critical başvuru uygulamaları kullanılarak bir korumalı alan uygulama ortamı oluşturulması kesinlikle önerilir.
Bu, hedef mimariyi çoğaltarak tasarım kararlarını doğrulamaya yönelik uygulamalı fırsatlar sağlar ve tasarım belirsizliğini hızla değerlendirmeye olanak tanır. Temsili gereksinim kapsamıyla doğru uygulanırsa, ilerlemeyi engelleme olasılığı olan sorunlu sorunların çoğu ortaya çıkarılabilir ve daha sonra giderilebilir.
6—Azure yol haritaları ile sürekli gelişme
Bu tasarım metodolojisi kullanılarak oluşturulan uygulama mimarileri, iyileştirilmiş sürdürülebilirliği desteklemek için Azure platformu yol haritalarıyla uyumlu bir şekilde gelişmeye devam etmelidir.
Sonraki adım
Görev açısından kritik uygulama senaryoları için tasarım ilkelerini gözden geçirin.