Omówienie scenariuszy hybrydowych

Ukończone

Załóżmy, że Twoja organizacja ma znaczną inwestycję w infrastrukturę programu SQL Server lokalnie i w lokalnych centrach danych. W takim przypadku ważne jest, aby pamiętać, że korzystanie z chmury nie jest propozycją typu "wszystko czy nic". Istnieją sposoby używania istniejącej infrastruktury lokalnej w pojemności hybrydowej z platformą Azure w celu zwiększenia odporności operacyjnej i obniżenia kosztów.

Zaimplementowanie infrastruktury hybrydowej jest również doskonałym pierwszym krokiem w ocenie przetwarzania w chmurze dla organizacji, które tradycyjnie były lokalne i sceptyczne dla chmury. Obecnie organizacje często mają połączenie fizycznych i zwirtualizowanych wdrożeń lokalnego programu SQL Server, które mogą rozszerzać chmurę w ramach rozwiązania hybrydowego. Hybrydowa platforma programu SQL Server oferuje korzyści zarówno w usługach lokalnych, jak i w chmurze; jest to bezpłatny środkowy grunt między nimi. Składnik chmury zwykle używa usług IaaS, takich jak magazyn lub maszyny wirtualne programu SQL Server, jak pokazano poniżej.

Diagram przedstawiający infrastrukturę lokalną i infrastrukturę chmurową z rozwiązaniem hybrydowym.

Oprócz rozszerzania rozwiązań lokalnych te same wzorce mogą być stosowane do istniejących alternatywnych rozwiązań w chmurze, co umożliwia implementacje hybrydowe chmury do chmury. Przejrzyjmy niektóre z najbardziej typowych scenariuszy hybrydowych dla programu SQL Server.

Scenariusze hybrydowe dla programu SQL Server

Zapoznajmy się z kilkoma strategiami wdrażania rozwiązania hybrydowego dla programu SQL Server.

Odzyskiwanie po awarii

Odzyskiwanie po awarii to najbardziej typowy scenariusz wdrożenia hybrydowego programu SQL Server. Odzyskiwanie po awarii oznacza, że organizacje zapewniają ciągłość działalności biznesowej w świetle katastroficznych zdarzeń. Organizacje mogą dystrybuować wdrożenia w wielu centrach danych na potrzeby trybu failover w podejściu lokalnym. Te centra danych zwykle znajdują się w tym samym regionie geograficznym co organizacja, co powoduje to podatność na bardziej znaczące katastrofy regionalne. Fizyczne centra danych są również kosztowne do wdrażania, monitorowania i konserwacji. Prawdopodobnie koszt uruchamiania maszyn wirtualnych programu Azure SQL Server w różnych regionach geograficznych jest znacznie mniejszy niż utworzenie nowego fizycznego centrum danych w innej lokalizacji geograficznej.

Diagram przedstawiający lokalny tryb failover z siedziby głównej do fizycznego centrum danych i hybrydowe przejście w tryb failover na platformę Azure z sieci lokalnej.

W tym podejściu hybrydowym platforma Azure jest używana do pracy w trybie failover odzyskiwania po awarii (do co najmniej jednego regionu), podczas gdy regularne codzienne przetwarzanie nadal korzysta z serwerów lokalnych na potrzeby lokalnej wysokiej dostępności.

Kopie zapasowe programu SQL Server

Kopie zapasowe programu SQL Server to inny typowy scenariusz hybrydowy. Kopie zapasowe można wykonywać bezpośrednio w usłudze Azure Storage za pośrednictwem adresu URL lub udziału plików platformy Azure (SMB). Ten scenariusz chroni przed utratą danych, gdy magazyn kopii zapasowych lokacji ulegnie awarii. Ponadto te kopie zapasowe mogą być również przywracane do maszyn wirtualnych na platformie Azure i testowane w ramach procedur odzyskiwania po awarii.

Inny scenariusz używa usługi Azure Storage do przechowywania lokalnych plików danych programu SQL Server dla baz danych użytkowników. Należy pamiętać, że są to pliki użytkownika, a nie systemowe bazy danych. W przypadku awarii magazynu lokalnego pliki użytkownika są bezpiecznie przechowywane w chmurze, co uniemożliwia utratę danych. Ponadto dzięki użyciu usługi Azure Storage istnieją wbudowane gwarancje niezawodności, dzięki czemu przechowywanie tych plików w chmurze jest bardziej odporne. W tym scenariuszu hybrydowym należy zapewnić bezpieczeństwo komunikacji sieciowej, ocenić opóźnienie sieci rozwiązania i upewnić się, że konto magazynu jest zablokowane przy użyciu list ACL i identyfikatora Entra firmy Microsoft.

Serwery SQL z obsługą usługi Azure Arc

Dzięki włączeniu usług SQL Server z obsługą usługi Azure Arc rozszerza i centralizuje usługi zarządzania platformy Azure do wystąpień programu SQL Server hostowanych lokalnie, w centrach danych, na brzegu i w środowiskach wielochmurowych. W tym scenariuszu hybrydowym usługa Azure Arc umożliwia spis wszystkich zarejestrowanych wdrożeń programu SQL Server i ocenia ich konfiguracje, wzorce użycia i zabezpieczenia w celu udostępnienia akcji i zaleceń w oparciu o najlepsze rozwiązania. Korzystając z serwerów SQL z obsługą usługi Azure Arc, zyskujesz korzyści z scentralizowanego zarządzania serwerem. Otrzymujesz również alerty zabezpieczeń usługi Azure Defender i raportowanie luk w zabezpieczeniach zarówno na lokalnych serwerach SQL, jak i w ich systemach operacyjnych hosta. Ponadto usługa Azure Sentinel może zapewnić więcej introspekcji zagrożeń bezpieczeństwa w razie potrzeby.

Diagram przedstawiający przykładową architekturę programu SQL Server z obsługą usługi Azure Arc.

Zagadnienia dotyczące zabezpieczeń

Podczas wdrażania hybrydowego rozwiązania SQL wszystkie podstawowe infrastruktury, takie jak Active Directory i DNS, muszą istnieć lokalnie i na platformie Azure. Ponadto bezpieczna komunikacja dwukierunkowa musi istnieć między siecią lokalną a platformą Azure. Ta zabezpieczona komunikacja może mieć formę sieci VPN typu lokacja-lokacja (S2S) lub dedykowanego tunelu usługi ExpressRoute . Podczas oceniania różnych metod łączności ważne jest określenie dopuszczalnego opóźnienia w organizacji. Niezależnie od wybranego rozwiązania zabezpieczenia sieci muszą również znajdować się w czołówce implementacji.

Diagram połączenia przedstawiający bramę sieci VPN typu lokacja-lokacja na platformie Azure.

Na powyższym obrazie przedstawiono korzyść rozwiązania sieci VPN typu lokacja-lokacja jest taka, że ma tendencję do mniejszego kosztu, a jego implementacja jest typowym zadaniem wśród inżynierów sieci. Jednak w przypadku tego rozwiązania cała komunikacja odbywa się za pośrednictwem publicznego Internetu i jest ograniczona przez szybkość internetu w organizacji.

Diagram połączenia przedstawiający połączenie usługi ExpressRoute z platformą Azure.

Jak widać powyżej, chociaż rozwiązanie usługi ExpressRoute wydaje się być bardziej kosztowne, zapewnia również najlepsze zabezpieczenia i najniższe opóźnienie, ponieważ wszystkie przepływy komunikacji za pośrednictwem bezpośredniego zabezpieczonego kanału niezależnie od publicznego Internetu. Jednak typowe przeciwniki tego rozwiązania obejmują całkowity koszt i niezdolność do stosowania usługi ExpressRoute między dostawcami chmury w rozwiązaniu wielochmurowym.