Metodologie návrhu pro klíčové úlohy v Azure
Vytvoření klíčové aplikace na jakékoli cloudové platformě vyžaduje významné technické znalosti a technické investice, zejména proto, že je zde značná složitost spojená s:
- Principy cloudové platformy
- Volba správných služeb a složení,
- Použití správné konfigurace služby
- Zprovoznění využívaných služeb a
- Neustálé sladění s nejnovějšími osvědčenými postupy a plány služeb
Tato metodologie návrhu se snaží poskytnout snadnou cestu návrhu, která vám pomůže zorientovat se v této složitosti a získat informace o rozhodnutích při návrhu potřebných k vytvoření optimální cílové architektury.
1. Návrh pro obchodní požadavky
Ne všechny důležité úlohy mají stejné požadavky. Očekávejte, že aspekty kontroly a doporučení k návrhu, které tato metodologie návrhu poskytuje, přinesou různá rozhodnutí o návrhu a kompromisy pro různé scénáře aplikací.
Vyberte úroveň spolehlivosti.
Spolehlivost je relativní koncept, a aby každá úloha byla náležitě spolehlivá, měla by odrážet obchodní požadavky, které s ní souvisí. Například kritická úloha s cílem úrovně služby (SLO) s 99,999% dostupností vyžaduje mnohem vyšší úroveň spolehlivosti než jiná méně důležitá úloha s cílem úrovně služeb 99,9 %.
Tato metodologie návrhu používá koncept úrovní spolehlivosti vyjádřených jako SLO dostupnosti, aby informovala o požadovaných charakteristikách spolehlivosti. Následující tabulka obsahuje povolené rozpočty chyb spojené s běžnými úrovněmi spolehlivosti.
| Úroveň spolehlivosti (SLO dostupnosti) | Povolený výpadek (týden) | Povolený výpadek (měsíc) | Povolený výpadek (rok) |
|---|---|---|---|
| 99,9 % | 10 minut, 4 sekundy | 43 minut, 49 sekund | 8 hodin, 45 minut, 56 sekund |
| 99,95 % | 5 minut, 2 sekundy | 21 minut, 54 sekund | 4 hodiny, 22 minut, 58 sekund |
| 99,99 % | 1 minuta | 4 minuty 22 sekund | 52 minut, 35 sekund |
| 99,999 % | 6 sekund | 26 sekund | 5 minut, 15 sekund |
| 99.9999% | <1 sekunda | 2 sekundy | 31 sekund |
Důležité
Cíl úrovně dostupnosti se v této metodologii návrhu považuje za více než jednoduchou dobu provozu, ale za konzistentní úroveň aplikační služby vzhledem ke známému stavu aplikace, který je v pořádku.
V počátečním cvičení doporučujeme čtenářům vybrat cílovou úroveň spolehlivosti a určit, jak velký výpadek je přijatelný? Úsilí o konkrétní úroveň spolehlivosti bude mít v konečném důsledku významný vliv na cestu návrhu a zahrnuje rozhodnutí o návrhu, což bude mít za následek jinou cílovou architekturu.
Tento obrázek ukazuje, jak různé úrovně spolehlivosti a základní obchodní požadavky ovlivňují cílovou architekturu pro koncepční referenční implementaci, zejména pokud jde o počet regionálních nasazení a využitých globálních technologií.
Dalšími důležitými aspekty při určování požadované spolehlivosti jsou plánovaná doba obnovení (RTO) a cíl bodu obnovení (RPO). Pokud se například snažíte dosáhnout doby obnovení aplikace kratší než minutu, pak strategie obnovení založené na zálohování nebo strategie aktivního-pasivního nasazení pravděpodobně nebudou stačit.
2 – Vyhodnocení oblastí návrhu pomocí principů návrhu
Jádrem této metodologie je kritická cesta návrhu, která se skládá z následujících částí:
- Základní principy návrhu
- Základní oblast návrhu s výrazně provázanými a závislými rozhodnutími o návrhu
Dopad rozhodnutí učiněných v každé oblasti návrhu se projeví v ostatních oblastech návrhu a rozhodnutích o návrhu. Projděte si uvedené aspekty a doporučení, abyste lépe porozuměli důsledkům souvisejících rozhodnutí, která mohou vést k kompromisům v souvisejících oblastech návrhu.
Pokud například chcete definovat cílovou architekturu, je důležité určit, jak nejlépe monitorovat stav aplikace napříč klíčovými komponentami. Důrazně doporučujeme, abyste si prostudovali oblast návrhu modelování stavu s využitím nastíněných doporučení, která vám pomůžou při rozhodování.
3. Nasazení první důležité aplikace
Projděte si tyto referenční architektury, které popisují rozhodnutí o návrhu na základě této metodologie.
Tip
Architektura je ověřená kritickou online implementací, která ilustruje doporučení návrhu.
Artefakty produkční úrovně Každý technický artefakt je připravený k použití v produkčních prostředích se všemi komplexními provozními aspekty.
Kořeny v reálných zkušenostech Všechna technická rozhodnutí se řídí zkušenostmi zákazníků Azure a poznatky z nasazení těchto řešení.
Sladění plánů plánu Azure Klíčové referenční architektury mají vlastní plán, který je v souladu s plány produktů Azure.
4. Integrace úloh v cílových zónách Azure
Předplatná cílové zóny Azure poskytují sdílenou infrastrukturu pro podniková nasazení, která vyžadují centralizované zásady správného řízení.
Je důležité vyhodnotit, který případ použití připojení vyžaduje vaše kritická aplikace. Cílové zóny Azure podporují dva hlavní archetypy oddělené do různých oborů skupin pro správu: Online nebo Corp. jak je znázorněno na tomto obrázku.
Online předplatné
Klíčové úlohy fungují jako nezávislé řešení bez přímého připojení k podnikové síti ke zbytku architektury cílové zóny Azure. Aplikace bude dále chráněna prostřednictvím zásad správného řízení řízeného zásadami a automaticky se integruje s centralizovaným protokolováním platformy prostřednictvím zásad.
Základní architektura a kritická online implementace jsou v souladu s přístupem online.
Předplatné společnosti
Při nasazení v předplatném společnosti Corp. je klíčová úloha závislá na cílové zóně Azure, která poskytuje prostředky připojení. Tento přístup umožňuje integraci s dalšími aplikacemi a sdílenými službami. Budete muset navrhnout některé základní prostředky, které budou existovat předem jako součást platformy sdílených služeb. Například razítko regionálního nasazení by už nemělo zahrnovat dočasný Virtual Network nebo Azure Privátní DNS Zone, protože budou existovat v předplatném Corp. .
Pokud chcete začít s tímto případem použití, doporučujeme základní architekturu v referenční architektuře cílové zóny Azure .
Tip
Předchozí architektura je ověřená implementací kritického připojení .
5. Nasazení aplikačního prostředí sandboxu
Souběžně s aktivitami návrhu se důrazně doporučuje vytvořit prostředí aplikace sandboxu pomocí Mission-Critical referenčních implementací.
To poskytuje praktické příležitosti k ověření rozhodnutí o návrhu replikací cílové architektury, což umožňuje rychle vyhodnotit nejistotu návrhu. Při správném použití se reprezentativním pokrytím požadavků je možné odhalit a následně vyřešit většinu problematických problémů, které by mohly bránit pokroku.
6. Průběžný vývoj s využitím plánů Azure
Architektury aplikací vytvořené pomocí této metodologie návrhu se musí i nadále vyvíjet v souladu s plány platformy Azure, aby podporovaly optimalizovanou udržitelnost.
Další krok
Projděte si principy návrhu pro klíčové scénáře aplikací.