Udostępnij przez

Sieć dla obciążeń SaaS na platformie Azure

Sieć zapewnia szkielet, w jaki sposób klienci uzyskują dostęp do aplikacji typu oprogramowanie jako usługa (SaaS) i umożliwiają komunikację między składnikami rozwiązania. Sposób projektowania sieci ma bezpośredni wpływ na zabezpieczenia, operacje, koszty, wydajność i niezawodność rozwiązania. Ustrukturyzowane podejście do strategii sieciowej staje się jeszcze ważniejsze w miarę rozwoju środowiska chmury.

Wybieranie strategii wdrażania sieci i topologii

Rozwiązania SaaS mają unikatowe wymagania dotyczące sieci. W miarę dołączania większej liczby klientów i ich użycia zmieniają się wymagania dotyczące sieci. Obsługa wzrostu może być trudna ze względu na ograniczone zasoby, takie jak zakresy adresów IP. Projekt sieci wpływa na bezpieczeństwo i izolację klientów. Zaplanuj strategię sieci, aby pomóc w zarządzaniu wzrostem, poprawić bezpieczeństwo i zmniejszyć złożoność operacyjną.

Uwagi dotyczące projektowania

  • Zaplanuj strategię wdrażania sieci na podstawie modelu dzierżawy. Zdecyduj, czy chcesz udostępniać zasoby sieciowe wśród klientów, dedykować zasoby pojedynczemu klientowi, czy też kombinację tych opcji. Ten wybór wpływa na funkcjonalność, zabezpieczenia i izolację klientów aplikacji.

    Wspólne jest udostępnianie zasobów sieciowych, takich jak sieci wirtualne i profile usługi Azure Front Door, wśród wielu klientów. Takie podejście zmniejsza koszty i nakłady operacyjne. Upraszcza również łączność. Zasoby klienta można łatwo połączyć z zasobami udostępnionymi, takimi jak udostępnione konta magazynu lub płaszczyzna sterowania.

    Jednak dedykowane zasoby sieciowe dla każdego klienta mogą być konieczne do ustanowienia wysokich zabezpieczeń i zgodności. Na przykład w celu obsługi wysokiego stopnia segmentacji sieci między klientami można użyć sieci wirtualnych jako granicy. Zasoby dedykowane mogą być konieczne, gdy liczba zasobów sieciowych dla wszystkich klientów przekracza pojemność pojedynczej udostępnionej sieci.

    Zaplanuj liczbę zasobów sieciowych, których potrzebuje każdy klient, uwzględniając natychmiastowe i przyszłe wymagania. Wymagania klienta i limity zasobów platformy Azure mogą wymuszać określone wyniki. Różne zasoby mogą wymagać różnych strategii wdrażania, takich jak używanie oddzielnych sieci do komunikacji równorzędnej sieci wirtualnych z sieciami wirtualnymi należącymi do klienta.

    Aby uzyskać więcej informacji na temat udostępniania zasobów w rozwiązaniu SaaS, zobacz Organizacja zasobów dla obciążeń SaaS.

  • Omówienie topologii sieci. Topologie sieci zwykle należą do trzech kategorii:

    • Sieć płaska: pojedyncza izolowana sieć, która ma podsieci na potrzeby segmentacji. Użyj topologii sieci płaskiej, jeśli masz jedną aplikację wielodostępną z prostym układem sieciowym. Sieci płaskie mogą osiągać limity zasobów i wymagać większej liczby sieci w miarę skalowania, co zwiększa obciążenie i koszty. Jeśli planujesz hostować wiele aplikacji lub używać dedykowanych sygnatur wdrażania w tej samej sieci wirtualnej, może być potrzebny złożony układ sieci.

    • Piasta i szprycha: scentralizowana sieć hubowa, która łączy się z izolowanymi sieciami szprych. Używaj topologii piasty i szprych w celu zapewnienia wysokiej skalowalności i izolacji klienta, ponieważ każdy klient lub aplikacja ma własną szprychę i komunikuje się tylko z piastą. W miarę potrzeb można szybko wdrożyć więcej szprych, aby wszystkie szprychy mogły korzystać z zasobów w koncentratorze. Przechodnia komunikacja między szprychami lub szprychami jest domyślnie wyłączona, co pomaga zachować izolację klientów w rozwiązaniach SaaS.

    • Brak sieci: używaj topologii bez sieci dla rozwiązań typu "platforma jako usługa" platformy Azure (PaaS), w których można hostować złożone obciążenia bez wdrażania sieci wirtualnych. Na przykład usługa aplikacja systemu Azure umożliwia bezpośrednią integrację z innymi usługami PaaS za pośrednictwem sieci szkieletowej platformy Azure. Chociaż takie podejście upraszcza zarządzanie, ogranicza elastyczność wdrażania mechanizmów kontroli zabezpieczeń i możliwości optymalizacji wydajności. Takie podejście może działać dobrze w przypadku aplikacji natywnych dla chmury. W miarę rozwoju rozwiązania należy spodziewać się przejścia do topologii piasty i szprych w czasie.

      Kompromis: Złożoność i bezpieczeństwo. Rozpoczęcie bez zdefiniowanej granicy sieci może zmniejszyć obciążenie operacyjne związane z zarządzaniem składnikami sieciowymi, takimi jak grupy zabezpieczeń, przestrzeń adresowa IP i zapory. Jednak obwód sieci jest niezbędny w przypadku większości obciążeń. W przypadku braku mechanizmów kontroli zabezpieczeń sieci polegaj na silnej tożsamości i zarządzaniu dostępem, aby chronić obciążenie przed złośliwym ruchem.

  • Dowiedz się, jak architektury obejmujące wiele regionów wpływają na topologie sieci. W architekturze obejmującej wiele regionów korzystających z sieci wirtualnych większość zasobów sieciowych jest wdrażana oddzielnie w każdym regionie, ponieważ zapory, bramy sieci wirtualnej i sieciowe grupy zabezpieczeń nie mogą być współużytkowane między regionami.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Zdecyduj, które składniki sieciowe są współużytkowane i które składniki są przeznaczone dla klienta.

Udostępnianie zasobów, które są naliczane za wystąpienie, takie jak Azure Firewall, Azure Bastion i Azure Front Door.		 Równoważ obsługę między wymaganiami dotyczącymi zabezpieczeń i izolacji, jednocześnie zmniejszając koszty i obciążenie operacyjne.
Zacznij od płaskiej topologii lub podejścia bez sieci.

Zawsze sprawdzaj wymagania dotyczące zabezpieczeń, ponieważ te podejścia oferują ograniczoną izolację i kontrolę ruchu.		 Złożoność i koszt rozwiązania można zmniejszyć, korzystając z prostszych topologii sieci.
Rozważ topologie piasty i szprych pod kątem złożonych potrzeb lub podczas wdrażania dedykowanych sieci wirtualnych dla każdego klienta. Użyj centrum do hostowania udostępnionych zasobów sieciowych w sieciach klientów. Możesz łatwiej skalować i zwiększyć efektywność kosztową, udostępniając zasoby za pośrednictwem sieci koncentratora.

Projektowanie obwodu sieci o wysokim poziomie bezpieczeństwa

Obwód sieci ustanawia granicę zabezpieczeń między aplikacją a innymi sieciami, w tym Internetem. Dokumentując obwód sieci, można odróżnić między następującymi typami przepływów ruchu:

  • Ruch przychodzący, który dociera do sieci ze źródła zewnętrznego.
  • Ruch wewnętrzny, który przechodzi między składnikami w sieci.
  • Ruch wychodzący, który opuszcza sieć.

Każdy przepływ obejmuje różne czynniki ryzyka i mechanizmy kontroli. Na przykład do inspekcji i przetwarzania ruchu przychodzącego potrzebnych jest wiele mechanizmów kontroli zabezpieczeń.

Ważne

Najlepszym rozwiązaniem jest zawsze przestrzeganie podejścia Zero Trust. Upewnij się, że cały ruch jest kontrolowany i sprawdzany, w tym ruch wewnętrzny.

Klienci mogą również mieć określone wymagania dotyczące zgodności, które wpływają na architekturę. Jeśli na przykład potrzebują zgodności z protokołem SOC 2, muszą zaimplementować różne mechanizmy kontroli sieci, w tym zaporę, zaporę aplikacji internetowej i sieciowe grupy zabezpieczeń, aby spełnić wymagania dotyczące zabezpieczeń. Nawet jeśli nie musisz od razu spełniać wymogów, rozważ te czynniki rozszerzalności podczas projektowania swojej architektury.

Aby uzyskać więcej informacji, zobacz SE:06 Recommendations for networking and connectivity (Zalecenia dotyczące sieci i łączności).

Uwagi dotyczące projektowania

  • Ochrona ruchu przychodzącego i zarządzanie nim. Sprawdź ten ruch pod kątem zagrożeń przychodzących.

    Zapory umożliwiają blokowanie złośliwych adresów IP i wykonywanie zaawansowanych analiz w celu ochrony przed próbami włamania. Jednak zapory mogą być kosztowne. Oceń wymagania dotyczące zabezpieczeń, aby określić, czy zapora jest wymagana.

    Aplikacje internetowe są narażone na typowe ataki, takie jak wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami i inne luki w zabezpieczeniach OWASP 10. Funkcja zapory aplikacji internetowej platformy Azure pomaga chronić przed tymi atakami i integrować się z usługami Azure Application Gateway i Azure Front Door. Przejrzyj warstwy dla tych usług, aby dowiedzieć się, które funkcje zapory aplikacji internetowej są w jakich produktach.

    Ataki typu "rozproszona odmowa usługi" (DDoS) stanowią zagrożenie dla aplikacji dostępnych w Internecie. Platforma Azure zapewnia podstawowy poziom ochrony bez ponoszenia kosztów. Usługa Azure DDoS Protection zapewnia zaawansowaną ochronę, ucząc się wzorców ruchu i odpowiednio dostosowując ochronę, ale te funkcje są kosztowne. Jeśli używasz usługi Azure Front Door, skorzystaj z wbudowanych funkcji DDoS.

    Poza zabezpieczeniami można również manipulować ruchem przychodzącym, aby zwiększyć wydajność aplikacji przy użyciu buforowania i równoważenia obciążenia.

    Rozważ użycie usługi zwrotnego serwera proxy, takiej jak Usługa Azure Front Door na potrzeby globalnego zarządzania ruchem HTTP i HTTPS. Alternatywnie użyj usługi Application Gateway lub innych usług platformy Azure na potrzeby kontroli ruchu przychodzącego. Aby uzyskać więcej informacji, zobacz Opcje równoważenia obciążenia.

  • Ochrona ruchu wewnętrznego. Upewnij się, że ruch między aplikacją a jej składnikami jest bezpieczny, aby zapobiec złośliwemu dostępowi. Chroń te zasoby i zwiększ wydajność przy użyciu ruchu wewnętrznego zamiast routingu przez Internet. Usługa Azure Private Link jest często używana do łączenia się z zasobami platformy Azure za pośrednictwem wewnętrznego adresu IP w sieci. W przypadku niektórych typów zasobów punkty końcowe usługi mogą być bardziej opłacalną alternatywą.

    Jeśli włączasz publiczny dostęp do Internetu dla swoich zasobów, należy zrozumieć, jak ograniczyć ruch przy użyciu adresów IP i tożsamości aplikacji, takich jak tożsamości zarządzane.

  • Ochrona ruchu wychodzącego. W niektórych rozwiązaniach sprawdź ruch wychodzący, aby zapobiec eksfiltracji danych, zwłaszcza w przypadku zgodności z przepisami i klientów korporacyjnych. Zapory umożliwiają zarządzanie ruchem wychodzącym i przeglądanie go przez blokowanie połączeń z nieautoryzowanymi lokalizacjami.

  • Planowanie skalowania łączności wychodzącej i sieci SNAT. Wyczerpanie portów translacji adresów sieciowych (SNAT) źródła może mieć wpływ na aplikacje wielodostępne. Te aplikacje często potrzebują odrębnych połączeń sieciowych dla każdej dzierżawy i współużytkowania zasobów między klientami zwiększają ryzyko wyczerpania SNAT w miarę wzrostu bazy klientów.

    Możesz wyeliminować wyczerpanie translatora adresów sieciowych przy użyciu usługi Azure NAT Gateway, zapór, takich jak usługa Azure Firewall, lub kombinacji tych dwóch podejść.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Zachowaj wykaz punktów końcowych sieci, które są uwidocznione w Internecie. Przechwyć szczegóły, takie jak adres IP (jeśli jest statyczny), nazwa hosta, porty, protokoły używane przez punkty końcowe i uzasadnienie połączeń.

Dokumentowanie sposobu ochrony każdego punktu końcowego.		 Ta lista stanowi podstawę definicji obwodowej, dzięki czemu można podejmować jawne decyzje dotyczące zarządzania ruchem za pośrednictwem rozwiązania.
Omówienie możliwości usługi platformy Azure w celu ograniczenia dostępu i zwiększenia ochrony.

Na przykład potrzebujesz większej liczby kontrolek, aby uwidocznić punkty końcowe konta magazynu klientom. Te kontrole obejmują podpisy dostępu współdzielonego, zapory sieciowe konta przechowywania i oddzielne konta przechowywania do użytku wewnętrznego i zewnętrznego.		 Możesz wybrać mechanizmy kontroli spełniające wymagania dotyczące zabezpieczeń, kosztów i wydajności.
W przypadku aplikacji opartych na protokole HTTP i HTTPS użyj zwrotnego serwera proxy, takiego jak azure Front Door lub Application Gateway. Odwrotne serwery proxy zapewniają szeroką gamę możliwości usprawnień wydajności, odporności i zabezpieczeń. Pomagają również zmniejszyć złożoność operacyjną.
Sprawdź ruch przychodzący przy użyciu zapory aplikacji internetowej (WAF).

Unikaj udostępniania zasobów internetowych, takich jak App Service lub Azure Kubernetes Service (AKS) bezpośrednio do Internetu.		 Możesz skuteczniej chronić aplikacje internetowe przed typowymi zagrożeniami i zmniejszyć ogólną ekspozycję rozwiązania.
Ochrona aplikacji przed atakami DDoS.

Użyj usługi Azure Front Door lub DDoS Protection w zależności od protokołów używanych przez publiczne punkty końcowe.		 Chroń rozwiązanie przed typowym typem ataku.
Jeśli Twoja aplikacja wymaga łączności wychodzącej na dużą skalę, użyj bramy NAT lub zapory sieciowej, aby zapewnić dodatkowe porty SNAT. Możesz obsługiwać wyższe poziomy skalowania.

Łączność między sieciami

W niektórych scenariuszach może być konieczne nawiązanie połączenia z zasobami spoza platformy Azure. Te zasoby obejmują dane w sieci prywatnej lub zasobach klienta u innego dostawcy usług w chmurze w konfiguracji wielochmurowej. Te potrzeby mogą komplikować projekt sieci, ponieważ wymagają różnych podejść do implementowania łączności między sieciami na podstawie określonych wymagań.

Uwagi dotyczące projektowania

  • Zidentyfikuj punkty końcowe, z którymi aplikacja musi nawiązać połączenie. Aplikacja może wymagać komunikacji z innymi usługami, takimi jak usługi magazynu i bazy danych. Dokumentowanie ich właściciela, lokalizacji i typu łączności. Następnie możesz wybrać odpowiednią metodę, aby nawiązać połączenie z tymi punktami końcowymi. W poniższej tabeli opisano typowe podejścia.

    Lokalizacja zasobu Właściciel Opcje łączności do rozważenia
    Azure Klient
    • Prywatny punkt końcowy (w dzierżawach firmy Microsoft Entra)
    • Komunikacja równorzędna sieci wirtualnych (w dzierżawach firmy Microsoft Entra)
    • Punkt końcowy usługi (w dzierżawach firmy Microsoft Entra)
    Inny dostawca usług w chmurze Niezależnego dostawcy oprogramowania lub klienta
    • Sieć VPN typu lokacja-lokacja
    • Azure ExpressRoute
    • Internet
    Lokalne Niezależnego dostawcy oprogramowania lub klienta
    • Sieć VPN typu lokacja-lokacja
    • ExpressRoute
    • Internet

    • Usługa Private Link i prywatne punkty końcowe zapewniają bezpieczną łączność z różnymi zasobami platformy Azure, w tym wewnętrznymi modułami równoważenia obciążenia dla maszyn wirtualnych. Umożliwiają one dostęp prywatny do rozwiązania SaaS dla klientów, ale są one związane z zagadnieniami dotyczącymi kosztów.

      Kompromis: Bezpieczeństwo i koszty. Usługa Private Link pomaga upewnić się, że ruch pozostaje w sieci prywatnej. Zalecamy usługę Private Link na potrzeby łączności sieciowej w dzierżawach firmy Microsoft Entra. Jednak każdy prywatny punkt końcowy wiąże się z kosztami, które mogą być dodawane w zależności od potrzeb zabezpieczeń. Punkty końcowe usługi mogą być opłacalną alternatywą. Zapewniają one ruch w sieci szkieletowej firmy Microsoft, zapewniając jednocześnie poziom łączności prywatnej.

    • Punkty końcowe usługi kierują ruch do zasobów PaaS za pośrednictwem sieci szkieletowej firmy Microsoft, która zabezpiecza komunikację między usługami. Punkty końcowe usługi mogą być opłacalne w przypadku aplikacji o wysokiej przepustowości, ale należy skonfigurować i zachować listy kontroli dostępu na potrzeby zabezpieczeń. Obsługa punktów końcowych usługi w tenantach Microsoft Entra różni się w zależności od usługi Azure. Zapoznaj się z dokumentacją produktu dla każdej używanej usługi.

    • Peering sieci wirtualnych łączy dwie sieci wirtualne i umożliwia zasobom w jednej sieci dostęp do adresów IP w drugiej. Ułatwia ona łączność z zasobami prywatnymi w sieci wirtualnej platformy Azure. Dostęp można zarządzać przy użyciu sieciowych grup zabezpieczeń, ale wymuszanie izolacji może być trudne. Dlatego ważne jest, aby zaplanować topologię sieci na podstawie konkretnych potrzeb klientów.

    • Wirtualne sieci prywatne (VPN) tworzą bezpieczny tunel przez Internet między dwiema sieciami, w tym między dostawcami chmury i lokalizacjami lokalnymi. Sieci VPN typu lokacja-lokacja używają urządzeń sieciowych w każdej sieci do konfiguracji. Oferują one opcję łączności o niskich kosztach, ale wymagają konfiguracji i nie gwarantują przewidywalnej przepływności.

    • Usługa ExpressRoute zapewnia dedykowane, wysokiej wydajności, prywatne połączenie między platformą Azure i innymi dostawcami usług w chmurze lub sieciami lokalnymi. Zapewnia przewidywalną wydajność i pomija ruch internetowy, ale wiąże się z wyższymi kosztami i wymaga bardziej złożonej konfiguracji.

  • Zaplanuj na podstawie miejsca docelowego. Może być konieczne nawiązanie połączenia z zasobami w różnych dzierżawach firmy Microsoft Entra, zwłaszcza jeśli zasób docelowy znajduje się w subskrypcji platformy Azure klienta. Rozważ użycie prywatnych punktów końcowych, sieci VPN typu lokacja-lokacja lub równorzędnych sieci wirtualnych. Aby uzyskać więcej informacji, zobacz Tworzenie połączenia równorzędnego sieci wirtualnej między różnymi subskrypcjami.

    Aby nawiązać połączenie z zasobami hostami innego dostawcy usług w chmurze, często należy używać publicznej łączności z Internetem, sieci VPN typu lokacja-lokacja lub usługi ExpressRoute. Aby uzyskać więcej informacji, zobacz Łączność z innymi dostawcami usług w chmurze.

  • Omówienie wpływu łączności na topologię sieci. Sieć wirtualna platformy Azure może mieć tylko jedną bramę sieci wirtualnej, która może łączyć się z wieloma lokalizacjami za pośrednictwem sieci VPN typu lokacja-lokacja lub usługi ExpressRoute. Istnieją jednak ograniczenia liczby połączeń, które można wykonać za pośrednictwem bramy, a izolowanie ruchu klientów może być trudne. W przypadku wielu połączeń z różnymi lokalizacjami należy odpowiednio zaplanować topologię sieci, wdrażając oddzielną sieć wirtualną dla każdego klienta.

  • Zapoznaj się z implikacjami planowania adresów IP. Niektóre podejścia do łączności zapewniają automatyczne tłumaczenie adresów sieciowych (NAT), co pomaga uniknąć problemów, które nakładające się adresy IP powodują. Jednak komunikacja równorzędna sieci wirtualnych i usługa ExpressRoute nie wykonują translatora adresów sieciowych. W przypadku korzystania z tych metod należy starannie zaplanować zasoby sieciowe i alokacje adresów IP, aby uniknąć nakładających się zakresów adresów IP i zapewnić przyszły wzrost. Planowanie adresów IP może być złożone, szczególnie w przypadku nawiązywania połączenia z zewnętrznymi źródłami, takimi jak klienci, więc rozważ potencjalne konflikty z ich zakresami adresów IP.

  • Omówienie rozliczeń ruchu wychodzącego sieci. Platforma Azure zwykle nalicza opłaty za wychodzący ruch sieciowy, gdy opuszcza sieć firmy Microsoft lub przenosi się między regionami platformy Azure. Podczas projektowania rozwiązań wielochmurowych lub wielochmurowych ważne jest, aby zrozumieć implikacje dotyczące kosztów. Opcje architektury, takie jak korzystanie z usługi Azure Front Door lub ExpressRoute, mogą mieć wpływ na sposób naliczania opłat za ruch sieciowy.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Wybierz metody sieci prywatnej do łączenia się między sieciami w celu nadania priorytetów zabezpieczeń.

Należy rozważyć routing przez Internet tylko wtedy, gdy ocenisz powiązane implikacje dotyczące zabezpieczeń i wydajności.		 Ruch prywatny przechodzi przez zabezpieczoną ścieżkę sieciową, która pomaga zmniejszyć wiele typów zagrożeń bezpieczeństwa.
Podczas nawiązywania połączenia z zasobami hostowanymi w środowiskach platformy Azure klientów, użyj usługi Private Link, punktów końcowych usługi lub peeringu sieci wirtualnych. Możesz zachować ruch w sieci firmy Microsoft, co pomaga zmniejszyć koszty i złożoność operacyjną w porównaniu z innymi podejściami.
W przypadku nawiązywania połączenia między dostawcami chmury lub sieciami lokalnymi użyj sieci VPN typu lokacja-lokacja lub usługi ExpressRoute. Te technologie zapewniają bezpieczne połączenia między dostawcami.

Wdrażanie w środowiskach klientów

Model biznesowy może wymagać hostowania aplikacji lub jej składników w środowisku platformy Azure klienta. Klient zarządza własną subskrypcją platformy Azure i bezpośrednio płaci koszt zasobów wymaganych do uruchomienia aplikacji. Jako dostawca rozwiązań odpowiadasz za zarządzanie rozwiązaniem, w tym początkowe wdrożenie, stosowanie konfiguracji i wdrażanie aktualizacji w aplikacji.

W takich sytuacjach klienci często korzystają z własnej sieci i wdrażają aplikację w zdefiniowanej przestrzeni sieciowej. Aplikacje zarządzane platformy Azure zapewniają możliwości ułatwiające ten proces. Aby uzyskać więcej informacji, zobacz Use an existing virtual network with Azure Managed Applications (Używanie istniejącej sieci wirtualnej z aplikacjami zarządzanymi platformy Azure).

Uwagi dotyczące projektowania

  • Przygotuj się do różnych zakresów adresów IP i konfliktów. Gdy klienci wdrażają sieci wirtualne i zarządzają nimi, są odpowiedzialni za obsługę konfliktów sieci i skalowania. Należy jednak przewidzieć różne scenariusze użycia klientów. Planowanie wdrożeń w środowiskach z minimalną przestrzenią adresową IP z wydajnym wykorzystaniem adresów IP. Unikaj twardego kodowania zakresów adresów IP, aby zapobiec ich nakładaniu się na zakresy klientów.

    Alternatywnie wdróż dedykowaną sieć wirtualną dla swojego rozwiązania. Możesz użyć usługi Private Link lub komunikacji równorzędnej sieci wirtualnych, aby umożliwić klientom łączenie się z zasobami. Aby uzyskać więcej informacji, zobacz Łączność między sieciami. Jeśli zdefiniowano punkty wejścia i wyjścia, oceń NAT jako sposób na wyeliminowanie problemów spowodowanych przez nakładające się adresy IP.

  • Zapewnianie dostępu do sieci na potrzeby zarządzania. Przejrzyj zasoby wdrażane w środowiskach klientów i zaplanuj dostęp do nich w celu monitorowania, zarządzania lub ponownego konfigurowania tych zasobów. Podczas wdrażania zasobów z prywatnymi adresami IP w środowisku należącym do klienta upewnij się, że masz ścieżkę sieciową, aby uzyskać do nich dostęp z własnej sieci. Zastanów się, jak ułatwić zmiany aplikacji i zasobów, takie jak wypychanie nowej wersji aplikacji lub aktualizowanie konfiguracji zasobów platformy Azure.

    W niektórych rozwiązaniach można używać funkcji zapewnianych przez aplikacje zarządzane platformy Azure, takich jak dostęp na żądanie i wdrażanie aktualizacji do aplikacji. Jeśli potrzebujesz większej kontroli, możesz hostować punkt końcowy w sieci klienta, z którym może się łączyć płaszczyzna sterowania. Takie podejście zapewnia dostęp do zasobów. Ta metoda wymaga większej liczby zasobów platformy Azure i programowania w celu spełnienia wymagań dotyczących zabezpieczeń, operacji i wydajności. Aby zapoznać się z przykładem implementacji tego podejścia, zobacz Przykład aktualizacji aplikacji zarządzanych platformy Azure.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Wdrażanie zasobów wdrożonych przez klienta i zarządzanie nimi za pomocą aplikacji zarządzanych platformy Azure. Aplikacje zarządzane platformy Azure udostępniają szereg funkcji, które umożliwiają wdrażanie zasobów i zarządzanie nimi w ramach subskrypcji platformy Azure klienta.
Zminimalizuj liczbę adresów IP używanych w przestrzeni sieciowej klienta. Klienci często mają ograniczoną dostępność adresów IP. Minimalizując ślad i oddzielając skalowanie od używania adresów IP, można rozszerzyć liczbę klientów, którzy mogą korzystać z rozwiązania, i umożliwić większy wzrost.
Zaplanuj, jak uzyskać dostęp sieciowy do zarządzania zasobami w środowiskach klientów, aby można było monitorować, zmiany konfiguracji zasobów i aktualizacje aplikacji. Możesz bezpośrednio skonfigurować zarządzane zasoby.
Zdecyduj, czy chcesz wdrożyć dedykowaną sieć wirtualną, czy zintegrować z istniejącą siecią wirtualną klienta. Decydując, która sieć wirtualna ma być używana z wyprzedzeniem, możesz upewnić się, że możesz spełnić wymagania klientów dotyczące izolacji, zabezpieczeń i integracji z innymi systemami.
Domyślnie wyłącz dostęp publiczny w zasobach platformy Azure. Wybierz prywatne wejście, jeśli jest to możliwe. Zmniejszasz zakres zasobów sieciowych, które ty i twoi klienci muszą chronić.

Dodatkowe zasoby

Multitenancy to podstawowa metodologia biznesowa projektowania obciążeń SaaS. Te artykuły zawierają więcej informacji dotyczących projektowania sieci:

Następny krok

Dowiedz się więcej o zagadnieniach dotyczących platformy danych dotyczących integralności danych i wydajności obciążeń SaaS na platformie Azure.

Obszar projektowania: dane dla obciążeń SaaS na platformie Azure

  • Last updated on