Łączność strefy lądowania danych w jednym regionie

W konfiguracji z jednym regionem strefa docelowa zarządzania danymi, strefy docelowe danych i wszystkie skojarzone usługi są ustanawiane w tym samym regionie. Wszystkie strefy docelowe znajdują się w ramach tej samej subskrypcji hubu sieciowego. Ta subskrypcja hostuje współdzielone zasoby sieciowe, które mogą obejmować wirtualne urządzenie sieciowe (takie jak Azure Firewall), bramę ExpressRoute, bramę sieci prywatnej VPN, sieć wirtualną typu hub lub wirtualną sieć WAN (koncentrator vWAN).

Rysunek 1. Łączność w jednym regionie.

Na podstawie bieżących możliwości usługi Azure Networking Services, zalecamy użycie architektury sieci w topologii siatki. Należy skonfigurować peering sieci wirtualnych między:

• Centrum łączności i strefa Zarządzanie danymi
• Centrum łączności i każda strefa docelowa danych
• Strefa Zarządzanie danymi i każda strefa docelowa danych
• Każda strefa docelowa danych

W tym artykule opisano zalety i wady każdej opcji architektury sieci rozważanej na potrzeby analizy w skali chmury.

Pierwsza sekcja tego artykułu koncentruje się na wzorcu pojedynczego regionu, w którym strefy Zarządzanie danymi i wszystkich stref docelowych danych są hostowane w tym samym regionie.

Każdy wzorzec projektu jest oceniany przy użyciu następujących kryteriów:

• Koszt
• Zarządzanie dostępem użytkowników
• Zarządzanie usługami
• Przepustowość
• Opóźnienie

Analizujemy każdą opcję projektu, mając na uwadze następujący przypadek użycia strefy docelowej międzysystemowej:

Architektura sieci mesh (zalecana)

Zalecamy użycie architektury siatki sieciowej podczas wdrażania analizy w skali chmury. Oprócz istniejącej konfiguracji sieci piasty i szprych w ramach dzierżawy należy wykonać dwie czynności w celu zaimplementowania architektury siatki sieciowej:

• Dodaj wirtualne sieci równorzędne między wszystkimi sieciami wirtualnymi strefy docelowej danych.
• Dodaj komunikację równorzędną sieci wirtualnych między strefami zarządzania danymi a wszystkimi strefami przechowywania danych.

W naszym przykładowym scenariuszu dane załadowane z konta magazynowego A są przesyłane przez peering sieci wirtualnej (2) skonfigurowany między dwiema sieciami Vnet strefy docelowej danych. Jest on ładowany i przetwarzany przez maszynę wirtualną B ((3) i (4)), a następnie wysyłany za pośrednictwem lokalnego prywatnego punktu końcowego (5) do przechowywania na koncie magazynu B.

W tym scenariuszu dane nie przechodzą przez centrum łączności. Pozostaje ona w obrębie platformy danych, która składa się ze strefy docelowej zarządzania danymi i co najmniej jednej strefy docelowej danych.

Rysunek 2. Architektura sieci z siatki.

Zarządzanie dostępem użytkowników w architekturze sieci zagęszczonej

W projekcie architektury sieci zagęszczonej zespoły aplikacji danych wymagają tylko dwóch elementów do tworzenia nowych usług (w tym prywatnych punktów końcowych):

• Dostęp do zapisu w dedykowanej grupie zasobów w strefie docelowej danych
• Dołączanie dostępu do wyznaczonej podsieci

W tym projekcie zespoły aplikacji danych mogą samodzielnie wdrażać prywatne punkty końcowe. Jeśli mają niezbędne prawa dostępu do połączenia prywatnych punktów końcowych z podsiecią w sieci typu spoke, wasze zespoły nie wymagają wsparcia przy konfigurowaniu potrzebnych połączeń.

Streszczenie:

Zarządzanie usługami w architekturze sieci zagęszczonej

W projekcie architektury sieci siatki żadne wirtualne urządzenie sieciowe nie działa jako pojedynczy punkt awarii lub ograniczanie przepustowości. Brak zestawów danych wysyłanych za pośrednictwem centrum łączności zmniejsza obciążenie centralnego zespołu platformy Azure, pod warunkiem, że nie trzeba skalować tego urządzenia wirtualnego w poziomie.

Oznacza to, że centralny zespół platformy Azure nie może już sprawdzać i rejestrować całego ruchu wysyłanego między strefami docelowymi danych. Jednak analiza w skali chmury to spójna platforma obejmująca wiele subskrypcji, która umożliwia skalowanie i przezwyciężenie ograniczeń na poziomie platformy, co nie jest wadą.

W przypadku wszystkich zasobów hostowanych w ramach jednej subskrypcji centralny zespół platformy Azure nie sprawdza już wszystkich danych w centralnym centrum łączności. Nadal można przechwytywać dzienniki sieciowe przy użyciu dzienników przepływu sieciowej grupy zabezpieczeń. Można konsolidować i przechowywać inne dzienniki aplikacji i poziomu usług przy użyciu ustawień diagnostycznych specyficznych dla usługi.

Wszystkie te dzienniki można przechwycić na dużą skalę przy użyciu definicji usługi Azure Policy dla ustawień diagnostycznych.

Ten projekt umożliwia również utworzenie natywnego rozwiązania DNS platformy Azure na podstawie stref Prywatna strefa DNS. Cykl życia rekordu A usługi DNS można zautomatyzować za pomocą definicji usługi Azure Policy dla prywatnych grup DNS.

Streszczenie:

Koszt architektury sieci siatkowej

W tym projekcie sieci płacisz tylko za:

• Prywatne punkty końcowe (na godzinę)
• Ruch przychodzący i wychodzący wysyłany przez prywatne punkty końcowe w celu załadowania nieprzetworzonego zestawu danych (1) i zapisania przetworzonego zestawu danych (6)

Opłaty za peerowanie sieci wirtualnych (2) nie będą naliczane, dlatego ta opcja ma minimalny koszt.

Streszczenie:

Przepustowość i opóźnienia w architekturze sieci kratowej

Ten projekt nie ma znanych ograniczeń przepustowości ani opóźnień, ponieważ żadne wirtualne urządzenia sieciowe nie ograniczają przepływności dla wymiany danych między strefami docelowymi. Jedynym czynnikiem ograniczającym projekt jest fizyczny limit naszych centrów danych (szybkość światłowodowych).

Streszczenie:

Podsumowanie architektury sieci siatkowej

Jeśli planujesz wdrożyć analizę w skali chmury, zalecamy użycie projektu sieci z siatką. Sieć z siatką oferuje maksymalną przepustowość i małe opóźnienia przy minimalnym koszcie, ale nie stanowi żadnych kompromisów dotyczących zarządzania dostępem użytkowników ani warstwy DNS.

Jeśli musisz wymusić inne zasady sieciowe na platformie danych, użyj sieciowych grup zabezpieczeń, a nie centralnych wirtualnych urządzeń sieciowych.

Tradycyjna architektura piasty i szprych (niezalecana)

Projekt architektury sieci piasty i szprych jest najbardziej oczywistą opcją i taką, którą przyjęło wiele przedsiębiorstw. W niej przechodniość sieci jest konfigurowana w centrum łączności w celu uzyskiwania dostępu do danych na koncie magazynu A z maszyny wirtualnej B. Dane przechodzą przez dwie wirtualne sieci równorzędne ((2) i (5)) oraz wirtualne urządzenie sieciowe hostowane w centrum łączności ((3) i (4)). Następnie dane są ładowane przez maszynę wirtualną (6) i przechowywane z powrotem na koncie magazynu B (8).

Rysunek 3. Architektura Hub and Spoke.

Zarządzanie dostępem użytkowników w tradycyjnej architekturze centralnej i rozgałęzionej

W tradycyjnym modelu typu piasta i szprychy zespoły ds. aplikacji danych potrzebują tylko dwóch rzeczy w celu tworzenia nowych usług (w tym Prywatnych Punktów Końcowych):

• Dostęp do zapisu w grupie zasobów w strefie docelowej danych
• Dołączanie dostępu do wyznaczonej podsieci

W tym projekcie zespoły aplikacji danych mogą samodzielnie wdrażać prywatne punkty końcowe. Jeśli mają niezbędne prawa dostępu do łączenia prywatnych punktów końcowych z podsiecią określonego węzła, zespoły nie potrzebują pomocy technicznej podczas konfigurowania wymaganej łączności.

Streszczenie:

Zarządzanie usługami w tradycyjnej architekturze hubowo-szprychowej

Ten projekt sieci jest dobrze znany i zgodny z istniejącą konfiguracją sieci w większości organizacji. Dzięki temu projekt jest łatwy do wyjaśnienia i wdrożenia. Możesz również użyć scentralizowanego rozwiązania DNS natywnego dla platformy Azure z strefami Prywatna strefa DNS, aby zapewnić rozpoznawanie nazw FQDN wewnątrz dzierżawy platformy Azure. Użycie stref Prywatna strefa DNS umożliwia zautomatyzowanie cyklu życia rekordu A systemu DNS za pomocą zasad platformy Azure.

Kolejną zaletą tego projektu jest to, że ruch jest kierowany przez centralne wirtualne urządzenie sieciowe, więc ruch sieciowy wysyłany z jednej szprychy do innej może być rejestrowany i sprawdzany.

Jednym z wad tego projektu jest to, że centralny zespół platformy Azure musi ręcznie zarządzać tabelami tras. Jest to konieczne, aby zapewnić przechodniość między szprychami, co umożliwia udostępnianie zasobów danych w wielu strefach docelowych danych. Zarządzanie trasami może stać się złożone i podatne na błędy w czasie i musi być brane pod uwagę z góry.

Kolejną wadą tej konfiguracji sieci jest sposób konfigurowania centralnego wirtualnego urządzenia sieciowego. Wirtualne urządzenie sieciowe działa jako pojedynczy punkt awarii i może spowodować poważny przestój wewnątrz platformy danych, jeśli wystąpi awaria. Ponadto w miarę zwiększania się rozmiarów zestawów danych w obrębie platformy danych i wzrostu liczby przypadków użycia strefy docelowej między danymi większa liczba ruchu jest wysyłana za pośrednictwem centralnego wirtualnego urządzenia sieciowego.

W czasie może to spowodować wysyłanie danych przez gigabajty, a nawet terabajty danych za pośrednictwem wystąpienia centralnego. Ponieważ przepustowość istniejących wirtualnych urządzeń sieciowych jest często ograniczona do tylko jednej lub dwucyfrowej przepływności gigabajtów, centralne wirtualne urządzenie sieciowe może stać się wąskim gardłem, które krytycznie ogranicza przepływ ruchu między strefami docelowymi danych i ogranicza możliwość udostępniania zasobów danych.

Jedynym sposobem uniknięcia tego problemu jest skalowanie centralnego wirtualnego urządzenia sieciowego w wielu wystąpieniach, co ma poważne konsekwencje dla tego projektu.

Streszczenie:

Koszt tradycyjnej architektury hub-and-spoke

W przypadku tej sieci opłaty są naliczane za godzinę za prywatne punkty końcowe kont magazynu. Opłaty są również naliczane za ruch przychodzący i wychodzący wysyłany za pośrednictwem prywatnych punktów końcowych w celu załadowania nieprzetworzonego zestawu danych (1) i za przechowywanie przetworzonego zestawu danych (8).

Naliczane są opłaty za ruch przychodzący i wychodzący peeringu jednej sieci wirtualnej (5). Jak wspomniano wcześniej, pierwsze połączenie równorzędne sieci wirtualnych nie jest naliczane (2).

Korzystanie z tej konfiguracji sieci (3) i (4) prowadzi do wysokich kosztów centralnego sprzętu wirtualnego. Musisz kupić dodatkowe licencje i skalować centralne wirtualne urządzenie sieciowe na podstawie zapotrzebowania lub zapłacić opłatę przetworzoną za gigabajt, ponieważ odbywa się to za pomocą usługi Azure Firewall.

Streszczenie:

Przepustowość i opóźnienie w tradycyjnej architekturze rodzaju "hub-and-spoke"

Ten projekt sieci ma poważne ograniczenia przepustowości. Centralne wirtualne urządzenie sieciowe staje się krytycznym wąskim gardłem w miarę wzrostu platformy, co ogranicza przypadki użycia strefy docelowej między danymi i udostępnianie zestawów danych. Prawdopodobnie również tworzy wiele kopii zestawów danych w czasie.

Ten projekt ma również duży wpływ na opóźnienie, co staje się szczególnie krytyczne w scenariuszach analizy w czasie rzeczywistym.

Streszczenie:

Podsumowanie tradycyjnej architektury modelu "Hub and Spoke"

Ten projekt sieci piasty i szprych ma zarządzanie dostępem i niektóre korzyści związane z zarządzaniem usługami, ale ze względu na krytyczne ograniczenia związane z zarządzaniem usługami i przepustowością i opóźnieniami nie możemy zalecić tego projektu sieci dla przypadków użycia strefy docelowej między danymi.

Architektura projekcji prywatnego punktu końcowego (niezalecane)

Inną opcją projektu jest projekcja prywatnych punktów końcowych w każdej i każdej strefie docelowej. W tym projekcie prywatny punkt końcowy dla konta magazynu A jest tworzony w każdej strefie docelowej. Prowadzi to do pierwszego prywatnego punktu końcowego w strefie docelowej danych A połączonego z siecią wirtualną w strefie docelowej danych A, drugiego prywatnego punktu końcowego połączonego z siecią wirtualną w strefie docelowej danych B itd.

To samo dotyczy konta magazynu B i potencjalnie innych usług w strefach docelowych danych. Jeśli zdefiniujemy liczbę stref docelowych danych jako n, w końcu znajdziemy n prywatnych punktów końcowych dla co najmniej wszystkich kont magazynu i potencjalnie innych usług w strefach docelowych danych. Prowadzi to do wykładniczego wzrostu liczby prywatnych punktów końcowych.

Rysunek 4. Architektura prognozowania prywatnego punktu końcowego.

Ponieważ wszystkie prywatne punkty końcowe określonej usługi (na przykład konto magazynu A) mają taką samą nazwę FQDN (na przykład storageaccounta.privatelink.blob.core.windows.net), to rozwiązanie stwarza wyzwania w warstwie DNS, których nie można rozwiązać przy użyciu stref Prywatna strefa DNS. Zamiast tego potrzebne jest niestandardowe rozwiązanie DNS umożliwiające rozpoznawanie nazw DNS na podstawie źródła/adresu IP osoby żądającej. Dzięki temu można nawiązać połączenie maszyny wirtualnej A z prywatnymi punktami końcowymi połączonymi z siecią wirtualną w strefie docelowej danych A, a następnie połączyć maszynę wirtualną B z prywatnymi punktami końcowymi połączonymi z siecią wirtualną w strefie docelowej danych B. Można to zrobić za pomocą konfiguracji opartej na systemie Windows Server, podczas gdy można zautomatyzować cykl życia rekordów A DNS za pomocą kombinacji dziennika aktywności i usługi Azure Functions.

W ramach tej konfiguracji można załadować nieprzetworzonego zestawu danych na koncie magazynu A do maszyny wirtualnej B, korzystając z zestawu danych za pośrednictwem lokalnego prywatnego punktu końcowego (1). Po załadowaniu i przetworzeniu zestawu danych ((2) i (3) można przechowywać go na koncie magazynu B, bezpośrednio korzystając z lokalnego prywatnego punktu końcowego (4). W tym scenariuszu dane nie mogą przechodzić przez żadne peeringi sieci wirtualnych.

Zarządzanie dostępem użytkowników w architekturze projekcji prywatnego punktu końcowego

Takie podejście do zarządzania dostępem użytkowników jest podobne do podejścia do architektury sieci z siatką. Jednak w tym projekcie można wymagać praw dostępu dla innych stref docelowych danych, aby utworzyć prywatne punkty końcowe nie tylko w wyznaczonej strefie docelowej danych i sieci wirtualnej, ale także w innych strefach docelowych danych i ich odpowiednich sieciach wirtualnych.

W związku z tym zespoły aplikacji danych wymagają trzech rzeczy, a nie dwóch, aby móc tworzyć nowe usługi:

• Dostęp do zapisu do grupy zasobów w wyznaczonej strefie docelowej danych
• Dołączanie dostępu do wyznaczonej podsieci
• Dostęp do grupy zasobów i podsieci we wszystkich pozostałych strefach docelowych danych w celu utworzenia odpowiednich lokalnych prywatnych punktów końcowych

Ten projekt sieci zwiększa złożoność warstwy zarządzania dostępem, ponieważ zespoły aplikacji danych wymagają uprawnień w każdej strefie docelowej danych. Projekt może być również mylący i prowadzić do niespójnej kontroli dostępu opartej na rolach w czasie.

Jeśli zespoły stref docelowych danych i zespoły aplikacji danych nie mają niezbędnych praw dostępu, wystąpią problemy opisane w tradycyjnej architekturze piasty i szprych (niezalecane).

Streszczenie:

Zarządzanie usługami w architekturze projekcji prywatnego punktu końcowego

Mimo że jest ponownie podobny do projektu architektury sieci siatki, ten projekt sieci ma korzyść z braku wirtualnego urządzenia sieciowego działającego jako pojedynczy punkt awarii lub ograniczania przepływności. Zmniejsza to również nakład pracy związany z zarządzaniem centralnym zespołem platformy Azure, nie wysyłając zestawów danych za pośrednictwem centrum łączności, ponieważ nie ma potrzeby skalowania urządzenia wirtualnego w poziomie. Oznacza to, że centralny zespół platformy Azure nie może już sprawdzać i rejestrować całego ruchu wysyłanego między strefami docelowymi danych. Jednak analiza w skali chmury to spójna platforma obejmująca wiele subskrypcji, która umożliwia skalowanie i przezwyciężenie ograniczeń na poziomie platformy, co nie jest wadą.

W przypadku wszystkich zasobów hostowanych w ramach jednej subskrypcji ruch nie jest sprawdzany w centralnym centrum łączności. Dzienniki sieciowe można nadal przechwytywać przy użyciu dzienników przepływu sieciowej grupy zabezpieczeń, a także konsolidować i przechowywać inne dzienniki aplikacji i poziomu usług przy użyciu ustawień diagnostycznych specyficznych dla usługi. Wszystkie te dzienniki można przechwycić na dużą skalę przy użyciu zasad platformy Azure. Z drugiej strony przestrzeń adresowa sieci wymagana przez platformę danych zwiększa się z powodu wykładniczego wzrostu wymaganych prywatnych punktów końcowych, co nie jest optymalne.

Głównymi problemami dotyczącymi tej architektury sieci są wcześniej wymienione wyzwania związane z systemem DNS. Nie można użyć natywnego rozwiązania platformy Azure w postaci prywatnych stref DNS, dlatego ta architektura wymaga rozwiązania innej firmy, które może rozpoznawać nazwy FQDN na podstawie źródła/adresu IP osoby żądającej. Należy również opracowywać i utrzymywać narzędzia oraz przepływy pracy w celu automatyzacji prywatnych rekordów A DNS, co znacząco zwiększa obciążenie związane z zarządzaniem w porównaniu z proponowanym rozwiązaniem opartym na działaniu Azure Policy .

Można utworzyć rozproszoną infrastrukturę DNS przy użyciu stref Prywatna strefa DNS, ale powoduje to utworzenie wysp DNS, co ostatecznie powoduje problemy podczas próby uzyskania dostępu do usług łącza prywatnego hostowanego w innych strefach docelowych w ramach dzierżawy. W związku z tym ten projekt nie jest realną opcją.

Streszczenie:

Koszt architektury projekcji prywatnego punktu końcowego

W tym projekcie sieci opłaty są naliczane tylko za prywatne punkty końcowe (na godzinę) oraz ruch przychodzący i wychodzący wysyłany za pośrednictwem tych prywatnych punktów końcowych w celu załadowania nieprzetworzonych zestawów danych (1) i przechowywania przetworzonych zestawów danych (4). Jednak dodatkowe koszty muszą być oczekiwane ze względu na wykładniczy wzrost liczby prywatnych punktów końcowych platformy danych. Ponieważ opłaty są naliczane za godzinę, kwota dodatkowych kosztów zależy od liczby utworzonych prywatnych punktów końcowych.

Streszczenie:

Przepustowość i opóźnienie w architekturze projekcji prywatnego punktu końcowego

Ten projekt nie ma znanych ograniczeń przepustowości i opóźnień, ponieważ nie ma żadnych wirtualnych urządzeń sieciowych, które ograniczają przepływność wymiany danych strefy docelowej między danymi. Jedynym czynnikiem ograniczającym projekt jest fizyczny limit naszych centrów danych (szybkość światłowodowych).

Streszczenie:

Podsumowanie architektury projekcji prywatnego punktu końcowego

Wykładniczy wzrost prywatnych punktów końcowych w tej architekturze sieci może spowodować utratę śladu, z których prywatnych punktów końcowych są używane w jakim celu. Problemy z zarządzaniem dostępem i złożoność warstw DNS są również ograniczone. Ze względu na te problemy nie możemy zalecić projektowania sieci dla przypadków użycia strefy docelowej między danymi.

Prywatne punkty końcowe w architekturze centrum łączności (niezalecane)

Inną opcją sieciową jest hostowanie prywatnych punktów końcowych w centrum łączności i łączenie ich z siecią wirtualną Koncentratora. W tym rozwiązaniu hostujesz pojedynczy prywatny punkt końcowy dla każdej usługi w firmowej sieci wirtualnej. Ze względu na istniejącą architekturę sieci piasty i szprych w większości korporacji, a fakt, że centrum łączności hostuje prywatne punkty końcowe w tym rozwiązaniu, przechodniość nie jest wymagana. Peering sieci wirtualnych między Hubem łączności a strefami lądowania danych umożliwia bezpośredni dostęp.

Dane przemieszczają się przez pojedyncze peerowanie sieci wirtualnej pomiędzy Centrum Łączności a Strefą Docelową Danych, aby załadować zestaw danych przechowywany na Koncie Magazynowym A z wykorzystaniem maszyny wirtualnej B. Po załadowaniu i przetworzeniu tego zestawu danych ((3) i (4)), następuje ponowne przejście przez to samo peerowanie sieci wirtualnej (5), zanim w końcu zostanie zapisane na Koncie Magazynowym B za pośrednictwem prywatnego punktu końcowego połączonego z siecią wirtualną Centrum (6).

Rysunek 5. Prywatne punkty końcowe w architekturze centrum łączności.

Zarządzanie dostępem użytkowników w architekturze centrum łączności

W tym projekcie sieci zespoły strefy docelowej danych oraz zespoły aplikacji danych potrzebują dwóch rzeczy, aby móc połączyć Prywatne Punkty Końcowe z wirtualną siecią Centrum:

• Uprawnienia do zapisu w grupie zasobów w subskrypcji usługi Connectivity Hub
• Dołączanie uprawnień do sieci wirtualnej koncentratora

Centrum łączności jest przeznaczone dla zespołu platformy Azure organizacji i jest przeznaczone do hostowania niezbędnej i udostępnionej infrastruktury sieciowej organizacji (w tym zapór, bram i narzędzi do zarządzania siecią). Ta opcja sieci sprawia, że projekt jest niespójny, ponieważ nie jest zgodny z zasadami zarządzania dostępem z zasad podstawowych strefy docelowej Enterprise-Scale. W związku z tym większość zespołów platformy Azure nie zatwierdzi tej opcji projektowania.

Streszczenie:

Zarządzanie usługami w architekturze centrum łączności

Podobnie jak w przypadku projektu architektury sieci siatki, ten projekt nie ma wirtualnego urządzenia sieciowego działającego jako pojedynczy punkt awarii ani przepływności ograniczania przepustowości. Zmniejsza to również nakład pracy związany z zarządzaniem centralnym zespołem platformy Azure, nie wysyłając zestawów danych za pośrednictwem centrum łączności, ponieważ nie ma potrzeby skalowania urządzenia wirtualnego w poziomie. Oznacza to, że centralny zespół platformy Azure nie może już sprawdzać i rejestrować całego ruchu wysyłanego między strefami docelowymi danych. Jednak analiza w skali chmury to spójna platforma obejmująca wiele subskrypcji, która umożliwia skalowanie i przezwyciężenie ograniczeń na poziomie platformy, co nie jest wadą.

W przypadku wszystkich zasobów hostowanych w ramach jednej subskrypcji ruch nie jest sprawdzany w centralnym centrum łączności. Dzienniki sieciowe można nadal przechwytywać przy użyciu dzienników przepływu sieciowej grupy zabezpieczeń, a także konsolidować i przechowywać inne dzienniki aplikacji i poziomu usług przy użyciu ustawień diagnostycznych specyficznych dla usługi. Wszystkie te dzienniki można przechwycić na dużą skalę przy użyciu zasad platformy Azure.

Ten projekt umożliwia również utworzenie natywnego rozwiązania DNS platformy Azure opartego na strefach Prywatna strefa DNS i umożliwia zautomatyzowanie cyklu życia rekordu A dns za pomocą zasad platformy Azure.

Streszczenie:

Koszt architektury centrum łączności

W tym projekcie sieci opłaty są naliczane tylko za prywatne punkty końcowe (na godzinę) oraz ruch przychodzący i wychodzący wysyłany za pośrednictwem tych prywatnych punktów końcowych w celu załadowania nieprzetworzonego zestawu danych (1) i przechowywania przetworzonego zestawu danych (6).

Streszczenie:

Przepustowość i opóźnienie w architekturze centrum łączności

Ten projekt nie ma znanych ograniczeń przepustowości i opóźnień, ponieważ nie ma żadnych wirtualnych urządzeń sieciowych, które ograniczają przepływność wymiany danych strefy docelowej między danymi. Jedynym czynnikiem ograniczającym projekt jest fizyczny limit naszych centrów danych (szybkość światłowodowych).

Streszczenie:

Podsumowanie architektury prywatnych punktów końcowych w centrum łączności

Chociaż ten projekt architektury sieci ma wiele korzyści, jego wcześniej wymienione niespójności zarządzania dostępem sprawiają, że jest podrzędny. W związku z tym nie możemy zalecić tego podejścia projektowego.

Podsumowanie dotyczące łączności strefy lądowania danych dla jednego regionu

Spośród wszystkich przeglądanych opcji architektury sieci, a ich zalety i wady, architektura sieci z siatki jest wyraźnym zwycięzcą. Ma ogromne korzyści z przepływności i zarządzania kosztami i zarządzaniem, dlatego zalecamy użycie jej podczas wdrażania analizy w skali chmury. Sieci wirtualne będące szprychami komunikacji równorzędnej nie były wcześniej powszechne i doprowadziło to do problemów z udostępnianiem zestawów danych między domenami i jednostkami biznesowymi.

Analizę w skali chmury można wyświetlać jako spójne rozwiązanie obejmujące wiele subskrypcji. W ramach konfiguracji pojedynczej subskrypcji przepływ ruchu sieciowego jest równy przepływowi w architekturze sieci z siatką. W ramach jednej konfiguracji subskrypcji użytkownicy najprawdopodobniej osiągną limity i limity przydziału na poziomie subskrypcji platformy, których celem jest analiza w skali chmury.

Następne kroki

• łączności strefy docelowej danych między regionami