Projektowanie architektury obciążenia przed migracją

W tym artykule opisano proces i zagadnienia dotyczące projektowania zamierzonego stanu zmigrowanego obciążenia w chmurze. W artykule opisano działania, które są częścią definiowania architektury obciążenia w ramach iteracji.

Artykuł na temat racjonalizacji przyrostowej wskazuje, że niektóre założenia architektoniczne są częścią każdej transformacji biznesowej, która obejmuje migrację. W tym artykule wyjaśniono typowe założenia. Wskazuje również na kilka przeszkód, które można uniknąć, i identyfikuje możliwości przyspieszenia wartości biznesowej, kwestionując założenia dotyczące architektury. Ten przyrostowy model projektowania architektury ułatwia zespołom szybsze i szybsze uzyskiwanie wyników biznesowych.

Podstawowy projekt architektury na podstawie typowych założeń

Następujące założenia są typowe dla dowolnego procesu migracji:

• Załóżmy, że obciążenie infrastruktury jako usługi (IaaS). Migracja obciążeń obejmuje przede wszystkim przeniesienie serwerów z fizycznego centrum danych do centrum danych w chmurze za pośrednictwem migracji IaaS. Proces zwykle wymaga minimalnego przebudowy lub ponownej konfiguracji. Takie podejście jest nazywane migracją metodą "lift and shift ".
• Zachowaj spójność architektury. Wprowadzanie zmian w architekturze podstawowej podczas migracji znacznie zwiększa złożoność. Debugowanie zmienionego systemu na nowej platformie wprowadza wiele zmiennych, które mogą być trudne do izolowania. Obciążenia powinny przechodzić tylko drobne zmiany podczas migracji, a wszelkie zmiany powinny być dokładnie przetestowane.
• Zaplanuj zmianę rozmiaru zasobów. Załóżmy, że kilka zasobów lokalnych w pełni korzysta z dowolnego zasobu. Przed migracją lub podczas migracji rozmiar zasobów zostanie zmieniony, aby najlepiej dopasować je do rzeczywistych wymagań dotyczących użycia. Narzędzia, takie jak Azure Migrate i Modernize, zapewniają ustalanie rozmiaru na podstawie rzeczywistego użycia.
• Przechwyć wymagania dotyczące ciągłości działania i odzyskiwania po awarii (BCDR). Jeśli masz uzgodnioną umowę dotyczącą poziomu usług (SLA) dla obciążenia już wynegocjowanego z firmą, kontynuuj korzystanie z umowy SLA po migracji na platformę Azure. Jeśli umowa SLA nie jest jeszcze ustawiona, zdefiniuj je przed zaprojektowaniem obciążenia w chmurze, aby upewnić się, że projektujesz odpowiednio.
• Zaplanuj przestój migracji. Podobnie jak w przypadku braku spełnienia wymagań umowy SLA, przestój, który występuje w przypadku podwyższenia poziomu obciążenia do środowiska produkcyjnego, może mieć negatywny wpływ na firmę. Czasami rozwiązania, które muszą przejść z minimalnym przestojem, wymagają zmian architektury. Przed rozpoczęciem planowania wydania należy założyć, że zostanie ustanowione ogólne zrozumienie wymagań dotyczących przestojów.
• Definiowanie wzorców ruchu użytkowników i aplikacji. Istniejące rozwiązania mogą zależeć od istniejących wzorców routingu sieciowego i rozwiązań. Zidentyfikuj zasoby potrzebne do obsługi bieżącego użycia sieci.
• Zaplanuj unikanie konfliktów sieci. W przypadku konsolidowania centrów danych w jednym dostawcy chmury prawdopodobnie wystąpią konflikty w systemie nazw domen (DNS) lub innych strukturach sieciowych. Podczas migracji ważne jest zaprojektowanie, aby uniknąć tych konfliktów, aby uniknąć przerw w działaniu systemów produkcyjnych hostowanych w chmurze.
• Planowanie tabel routingu. Upewnij się, że projekt zawiera plan modyfikowania tabel routingu w przypadku konsolidowania sieci lub centrów danych. Rozważ wymagania dotyczące routingu między centrami danych.

Architektura projektowania strefy docelowej

W fazie Gotowości przewodnika Cloud Adoption Framework organizacja wdrożyła udostępnione usługi platformy w ramach wdrażania stref docelowych platformy Azure. W obszarze Gotowość strefy docelowej do migracji przygotowano strefę docelową do odbierania migrowanych obciążeń.

Na podstawie tego planowania można założyć, że istnieją następujące składniki migracji:

• Łączność hybrydowa łączy sieci platformy Azure z sieciami lokalnymi.
• Sieciowe urządzenia zabezpieczeń, takie jak Azure Firewall, obsługują inspekcję ruchu poza obciążeniem.
• Zasady platformy Azure w celu wymuszania praktyk ładu, takich jak wymagania dotyczące rejestrowania, dozwolone regiony, niedozwolone usługi i inne mechanizmy kontroli są aktywne.
• Obszar roboczy dzienników usługi Azure Monitor na potrzeby rejestrowania udostępnionego jest konfigurowany w usłudze Azure Monitor.
• Ustanawiane są zasoby tożsamości udostępnionej do obsługi serwerów przyłączonych do domeny lub innych potrzeb związanych z tożsamością.

Jeśli te podstawowe elementy migracji nie zostały ustanowione, twoja organizacja powinna natychmiast wrócić do fazy Gotowe, aby spełnić te potrzeby. Bez tych składników migracja prawdopodobnie będzie miała opóźnienia i niepowodzenia i będzie mniej skuteczna.

Pakiet roboczy, który projektujesz, ma przypisaną subskrypcję, najlepiej przez proces sprzedaż abonamentów. Subskrypcja może zawierać kilka obciążeń lub tylko jedno obciążenie w zależności od tego, jak organizacja ukończyła swoją organizację zasobów dla obciążeń. W przypadku migracji obciążenia, które ma wiele środowisk aplikacji, możesz nawet mieć wiele subskrypcji na podstawie wskazówek dotyczących środowisk aplikacji.

Projektowanie architektury sieci obciążenia

Zaplanuj wdrażanie zasobów specyficznych dla aplikacji w określonej subskrypcji i planowanie projektowania dedykowanej sieci wirtualnej dla obciążenia. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące projektowania architektury sieci. Szczególnie należy skoncentrować się na segmentowaniu sieci wirtualnych.

Sieć prawdopodobnie potrzebuje zasobów, takich jak moduły równoważenia obciążenia i inne zasoby dostarczania aplikacji. Aby zaplanować te zasoby na platformie Azure, możesz użyć przewodnika po architekturze N-warstwowej.

Projektowanie zależności obciążeń

Narzędzia do oceny migracji powinny umożliwiać analizę zależności, na przykład analizę zależności w usłudze Azure Migrate i modernizację. Narzędzie ułatwia identyfikowanie współzależności między serwerami.

Oprócz planowania architektury samego obciążenia może być konieczne rozważenie zależności między obciążeniami. Na przykład niektóre obciążenia mogą wymagać częstej komunikacji. Jeśli tak, planowanie fal migracji i zależności w celu uwzględnienia tego wymagania pomaga w pomyślnej migracji.

Aby zaprojektować sposób działania połączonych obciążeń po migracji, możesz użyć wskazówek w centrum architektury platformy Azure, takich jak sieć szprychy .

Przygotowanie do wdrożenia poufnego przetwarzania

Podzbiór obciążeń z wymaganiami dotyczącymi niezależności może prowadzić do korzystania z poufnego przetwarzania. W ramach wdrożenia suwerennej strefy docelowej tworzone są grupy zarządzania na potrzeby poufnego przetwarzania.

W kontekście suwerenności użycie poufnego przetwarzania wymaga usługi Azure Key Vault i kluczy zarządzanych przez klienta jako usługi pomocniczej. Aby uzyskać więcej informacji, zobacz Szyfrowanie za pomocą kluczy zarządzanych przez klienta w usłudze Microsoft Cloud for Sovereignty.

Aktualizowanie początkowego oszacowania chmury

Po zakończeniu projektowania architektury wróć do szacowania chmury, aby upewnić się, że nadal znajdujesz się w zaplanowanym budżecie. W miarę dodawania usług pomocniczych, takich jak moduły równoważenia obciążenia lub kopie zapasowe, koszty mogą ulec zmianie. Chociaż możesz używać narzędzi, takich jak przypadki biznesowe w usłudze Azure Migrate i modernizować, aby wykonać szczegółowe ćwiczenia związane z zarządzaniem kosztami, należy okresowo ponownie zapoznać się z oszacowaniami w miarę dostosowywania projektu architektury.

Jeśli znasz tradycyjne procesy zaopatrzenia IT, szacowanie zasobów w chmurze może wydawać się obce. W przypadku wdrażania technologii w chmurze pozyskiwanie przechodzi od sztywnego, ustrukturyzowanego modelu wydatków kapitałowych do płynnego modelu wydatków operacyjnych. Planowanie migracji do chmury często polega na pierwszym napotkaniu tej zmiany przez organizację lub zespół IT.

W tradycyjnym modelu wydatków kapitałowych zespół IT próbuje połączyć moc nabywcza dla wielu obciążeń w różnych programach. Takie podejście umożliwia scentralizowanie puli udostępnionych zasobów IT, które mogą obsługiwać każde z tych rozwiązań. W modelu chmury wydatków operacyjnych koszty mogą być bezpośrednio przypisywane do potrzeb pomocy technicznej poszczególnych obciążeń, zespołów lub jednostek biznesowych. Zapewnia organizacji bardziej bezpośrednie przypisywanie kosztów klientom wewnętrznym i celom biznesowym, które obsługują. To bardziej dynamiczne podejście do zarządzania finansami jest często nazywane operacjami finansowymi (FinOps). Mimo że FinOps nie jest kwestią specyficzną dla platformy Azure, warto mieć rozszerzoną wiedzę na temat metodyki FinOps. Aby uzyskać więcej informacji, zobacz Co to jest FinOps?.

Podczas projektowania architektury obciążenia na potrzeby migracji możesz użyć kalkulatora cen z informacjami o ocenie, aby zrozumieć cenę całego obciążenia.

Ponadto po przeprowadzeniu migracji obciążenia należy kontynuować pracę, aby zoptymalizować koszty obciążeń. Aby uzyskać więcej informacji na temat tego, jak organizacje mogą rozwijać swoje umiejętności w zakresie zarządzania kosztami, zobacz Ulepszanie dyscypliny zarządzania kosztami.

Dowiedz się, kiedy zmienić architekturę

Migracje mają tendencję do utrzymywania istniejącej architektury i przenoszenia jej na platformę w chmurze. Jednak czasami może być konieczne zmiana architektury obciążenia, nawet w przypadku migracji. Ta lista zawiera przykłady, kiedy może być konieczne wprowadzenie zmian architektury przed przeprowadzeniem migracji:

• Płacenie za dług techniczny. Niektóre starzejące się obciążenia mają duże zadłużenie techniczne. Dług techniczny może prowadzić do długoterminowych wyzwań, zwiększając koszty hostingu u dowolnego dostawcy usług w chmurze. Jeśli dług techniczny nienaturalnie zwiększa koszty hostingu, należy ocenić alternatywne architektury.
• Poprawa niezawodności. Standardowe punkty odniesienia operacji zapewniają stopień niezawodności i odzyskiwania w chmurze. Niektóre zespoły ds. obciążeń mogą wymagać wyższych umów SLA, co może prowadzić do zmian architektury.
• Obciążenia o wysokich kosztach. Podczas migracji należy zoptymalizować wszystkie zasoby, aby dostosować rozmiar do rzeczywistego użycia. Niektóre obciążenia mogą wymagać modyfikacji architektury w celu rozwiązania określonych problemów związanych z kosztami.
• Wymagania dotyczące wydajności. Jeśli wydajność obciążenia ma bezpośredni wpływ na działalność biznesową, może być wymagana dodatkowa kwestia architektury.
• Zabezpieczanie aplikacji. Wymagania dotyczące zabezpieczeń są zwykle implementowane centralnie i są zwykle stosowane do wszystkich obciążeń w portfolio. Niektóre obciążenia mogą mieć określone wymagania dotyczące zabezpieczeń, które mogą prowadzić do zmian architektury.

Każde z tych kryteriów służy jako wskaźnik potencjalnego przeszkody migracji. W większości przypadków można rozwiązać kryterium po przeprowadzeniu migracji obciążenia przez odpowiednie serwery, dodanie nowych serwerów lub wprowadzenie innych zmian. Jeśli jednak którekolwiek z tych kryteriów jest wymagane przed migracją obciążenia, usuń obciążenie z fali migracji i oceń je indywidualnie.

Dobrze zaprojektowana struktura platformy Azure i przegląd dobrze zaprojektowanej architektury platformy Azure mogą pomóc w prowadzeniu rozmów z właścicielem technicznym określonego obciążenia, aby ułatwić im rozważenie alternatywnych opcji wdrażania obciążenia.

Obciążenie jest następnie klasyfikowane jako nakład pracy z architekturą lub modernizacją w planie wdrożenia chmury. Ze względu na dodatkowy czas potrzebny na zmianę obciążenia należy wziąć pod uwagę te alternatywne ścieżki wdrażania obciążenia jako oddzielne od procesu migracji.

Lista kontrolna architektury

Poniższa lista kontrolna umożliwia upewnienie się, że zostały omówione krytyczne zagadnienia dotyczące architektury:

• Upewnij się, że twoja architektura spełnia umowy SLA dotyczące dostępności, odzyskiwania po awarii i odzyskiwania danych.
• Upewnij się, że zastosowano praktyki segmentacji sieci do projektu sieci.
• Upewnij się, że planowane jest monitorowanie i przechwytywanie dzienników.
• Upewnij się, że maszyny wirtualne mają odpowiedni rozmiar dla rzeczywistego czasu obliczeniowego, który jest potrzebny.
• Upewnij się, że dyski mają odpowiedni rozmiar dla rzeczywistego rozmiaru i wydajności, które są potrzebne.
• Upewnij się, że planowane są usługi równoważenia obciążenia, jeśli są potrzebne. Usługi mogą obejmować wystąpienia usługi Azure Load Balancer, aplikacja systemu Azure Gateway, Azure Front Door lub Azure Traffic Manager.
• Upewnij się, że planowane są wymagania dotyczące niezależności i poufnego przetwarzania, jeśli są potrzebne.

Następny krok

Wdrażanie obciążeń migracji