Bereitstellen von hoch verfügbaren NVAs

In diesem Artikel werden allgemeine Methoden zum Bereitstellen einer Reihe virtueller Netzwerkgeräte (NVAs) für hohe Verfügbarkeit in Azure beschrieben. Ein NVA steuert in der Regel den Datenverkehrsfluss zwischen Netzwerksegmenten, die unterschiedliche Sicherheitsstufen aufweisen. Sie können z. B. einen NVA zwischen einem virtuellen Umkreisnetzwerk und dem öffentlichen Internet verwenden oder externe Standorte über vpn (Virtual Private Network) oder softwaredefinierte WAN(SD-WAN)-Appliances mit Azure verbinden.

In diesem Artikel wird davon ausgegangen, dass Sie ein grundlegendes Verständnis von Azure-Netzwerken, Azure-Lastenausgleichsmodulen, routing virtueller Netzwerkdatenverkehr und benutzerdefinierten Routen (UDRs) haben.

Viele Entwurfsmuster verwenden NVAs, um den Datenverkehr zwischen verschiedenen Sicherheitszonen zu analysieren. Diese Muster können NVAs für die folgenden Zwecke verwenden:

• Um ausgehenden Datenverkehr von virtuellen Maschinen ins Internet zu prüfen und Datenexfiltration zu verhindern.

• Um Datenverkehr vom Internet auf virtuelle Computer zu prüfen und Angriffe zu verhindern.

• So filtern Sie den Datenverkehr zwischen virtuellen Computern in Azure, um laterale Verschiebungen kompromittierter Systeme zu verhindern.

• Zum Filtern des Datenverkehrs zwischen lokalen Systemen und virtuellen Azure-Computern, insbesondere, wenn sie zu verschiedenen Sicherheitsstufen gehören. Beispielsweise hostet Azure das Umkreisnetzwerk, während die lokale Umgebung die internen Anwendungen hostet.

• Zum Beenden von VPN- oder SD-WAN-Tunneln, die von externen Quellen wie lokalen Netzwerken oder anderen öffentlichen Clouds stammen.

Sie können einem Azure-Design die folgenden NVAs hinzufügen, indem Sie die Muster in diesem Artikel verwenden:

• Netzwerkfirewalls
• Ebene-4-Reverseproxys
• INTERNET Protocol Security (IPsec)-VPN-Endpunkte
• SD-WAN-Appliances
• Webbasierte Reverse-Proxys mit Webanwendungs-Firewall-Funktionen
• Internetproxys, um einzuschränken, auf welche Internetseiten über Azure zugegriffen werden kann
• Layer-7-Lastenausgleichsgeräte

Azure-native NVAs wie Azure Firewall und Azure Application Gateway verwenden die weiter unten in diesem Artikel erläuterten Designs. Sie sollten diese Optionen aus der Entwurfsperspektive und für Netzwerkproblembehandlungszwecke verstehen.

NVAs erfordern häufig hohe Verfügbarkeit, da sie die Kommunikation zwischen Netzwerksegmenten steuern. Wenn NVAs nicht verfügbar sind, kann der Netzwerkdatenverkehr nicht ablaufen, und Anwendungen funktionieren nicht mehr. Geplante und ungeplante Ausfälle beenden gelegentlich NVA-Instanzen, ähnlich wie andere virtuelle Computer in Azure oder in anderen Clouds. Die NVA-Instanzen werden möglicherweise heruntergefahren, selbst wenn Sie sie mit Azure Premium-SSDs konfigurieren, die ein Service-Level-Agreement für eine einzelne Instanz in Azure bieten. Hoch verfügbare Anwendungen erfordern mindestens zwei NVAs, um die Konnektivität sicherzustellen.

Wenn Sie die beste Option für die Bereitstellung eines NVA in einem virtuellen Azure-Netzwerk auswählen, ist der wichtigste Aspekt, ob der NVA-Anbieter sein Design bewertet und überprüft hat. Der Anbieter muss auch die erforderliche NVA-Konfiguration bereitstellen, um die NVA in Azure zu integrieren. Wenn der NVA-Anbieter mehrere unterstützte Designoptionen bereitstellt, sollten Sie die folgenden Faktoren berücksichtigen, um Ihre Entscheidung zu treffen:

• Konvergenzzeit: Die Zeit, die jedes Design benötigt, um den Datenverkehr von einer fehlgeschlagenen NVA-Instanz umzuleiten

• Topologieunterstützung: Die NVA-Konfigurationen, die jede Designoption unterstützt, wie z. B. aktiv/aktiv, aktiv/standby oder skalierbare NVA-Cluster mit einer zusätzlichen Einheit für Redundanz.

• Verkehrssymmetrie: Gibt an, ob das NVA gezwungen wird, die Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) auf den Paketen durchzuführen, um asymmetrisches Routing zu vermeiden, oder ob der Entwurf die Datenverkehrssymmetrie durch andere Mittel erzwingt.

Hinweis

Dieser Artikel befasst sich mit Hub-and-Spoke-Entwürfen. In diesem Artikel wird Azure Virtual WAN nicht behandelt, da es detailliertere Richtlinien für die Bereitstellung von NVAs enthält, je nachdem, ob ein virtueller Wan-Hub eine bestimmte NVA unterstützt. Weitere Informationen finden Sie unter NVAs in einem virtuellen WAN-Hub.

In den folgenden Abschnitten werden allgemeine Architekturen beschrieben, die Sie zum Integrieren von NVAs in ein Hub-and-Spoke-Netzwerk verwenden können.

Übersicht über Hochverfügbarkeitsarchitekturen

Lösung	Vorteile	Überlegungen
Azure-Lastenausgleich	Diese Lösung unterstützt die Konfigurationen aktiv/aktiv und aktiv/Standby sowie horizontal skalierende NVAs mit guter Konvergenzzeit.	Der NVA muss einen Port für die Integritätssonden bereitstellen, insbesondere für Aktive/Standby-Bereitstellungen. Für zustandsbehaftete Appliances, wie Firewalls, die eine Datenverkehrssymmetrie erfordern, ist SNAT für den Datenverkehr von und zum Internet erforderlich.
Azure Route Server	Die NVA muss das Border Gateway Protocol (BGP) unterstützen. Diese Lösung unterstützt die Konfigurationen aktiv/aktiv und aktiv/Standby sowie horizontal skalierende NVAs.	Die Verkehrssymmetrie erfordert SNAT in dieser Lösung.
Azure Gateway Load Balancer	Die Verkehrssymmetrie ist ohne SNAT garantiert. NVAs können mandantenübergreifend freigegeben werden. Diese Lösung hat eine gute Konvergenzzeit und unterstützt die Konfigurationen aktiv/aktiv, aktiv/Standby sowie horizontal skalierende NVAs.	Diese Lösung unterstützt Datenströme zu und aus dem Internet und unterstützt keine East-West Datenströme.
Dynamische private IP-Adresse und UDR	Die NVA erfordert keine besonderen Features. Diese Lösung garantiert symmetrischen Datenverkehr.	Diese Lösung ist nur für aktive/passive Designs vorgesehen. Es hat eine hohe Konvergenzzeit von ein bis zwei Minuten.

Lastverteiler

Das Lastenausgleichsdesign verwendet zwei Azure-Lastenausgleichsgeräte, um einen Cluster von NVAs für den Rest des Netzwerks verfügbar zu machen. Der Ansatz eignet sich sowohl für statusbehaftete als auch für statusfreie NVAs.

• Ein interner Lastenausgleich leitet internen Datenverkehr von Azure und der lokalen Umgebung an die NVAs um. Dieser interne Lastenausgleich ist mit Regeln für hohe Verfügbarkeit konfiguriert , sodass jeder TCP-Port (Transmission Control Protocol) und der UDP-Port (User Datagram Protocol) an die NVA-Instanzen umgeleitet werden.

• Ein öffentlicher Lastenausgleich verbindet die NVAs mit dem Internet. Hochverfügbarkeitsports sind für eingehenden Datenverkehr bestimmt, daher muss jeder TCP/UDP-Port in einer dedizierten Lastenausgleichsregel geöffnet werden.

Das folgende Diagramm zeigt die Sequenz von Hops, die von Paketen aus dem Internet an einen Anwendungsserver in einem virtuellen Spoke-Netzwerk übertragen werden. Diese Pakete durchlaufen eine Firewall-NVA, um den Datenverkehr vom und zum öffentlichen Internet zu steuern, auch als Nord-Süd-Datenverkehr bezeichnet.

Dieses Diagramm zeigt einen Hub und zwei Speichen. Der Hub enthält ein Gateway-Subnetz und ein NVA-Subnetz. Das Gatewaysubnetz enthält ein VPN- oder Azure ExpressRoute-Gateway. Das NVA-Subnetz enthält einen internen Azure-Lastenausgleich und NVAs. Jede Speichen enthält einen App-Server. Spoke2 enthält eine Notiz, die wie folgt lautet: Spokeroutentabelle 0.0.0.0/0 nach 10.0.0.36 und Gatewayweiterleitung deaktivieren. Eingehender Datenverkehr fließt vom öffentlichen Internet zu den NVAs über den öffentlichen Azure-Lastenausgleich. Dieser Datenverkehr fließt dann in Spoke2 zum App-Server. Der Rückgabedatenverkehr fließt von diesem App-Server über den internen Azure Load Balancer zu den NVAs. Dieser Datenverkehr fließt dann in das öffentliche Internet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Um Datenverkehr von Spokes über die NVAs an das öffentliche Internet zu senden, verwendet dieser Entwurf eine UDR für 0.0.0.0/0. Der nächste Hop ist die IP-Adresse des internen Lastenausgleichs.

Für den Datenverkehr zwischen Azure und dem öffentlichen Internet überschreitet jede Richtung des Datenverkehrs einen anderen Azure-Lastenausgleich. Dieser Vorgang tritt auch dann auf, wenn die Firewall-NVA über eine einzelne Netzwerkschnittstellenkarte (NIC) für die öffentlichen und internen Netzwerke verfügt, da das Eingangspaket den öffentlichen Azure-Lastenausgleich durchläuft und das Ausgangspaket den internen Azure-Lastenausgleich durchläuft. Beide Richtungen des Flusses durchlaufen verschiedene Lastenausgleichsgeräte. Wenn Sie also die Datenverkehrssymmetrie benötigen, müssen die NVA-Instanzen SNAT ausführen, um den Rückgabeverkehr anzuziehen und die Datenverkehrssymmetrie sicherzustellen. Die meisten Firewalls erfordern die Datenverkehrssymmetrie.

Das folgende Diagramm zeigt, wie Sie den gleichen Lastenausgleichsentwurf verwenden, um den Datenverkehr zwischen Azure und lokalen Netzwerken oder East-West Datenverkehr zu prüfen, der nur einen internen Lastenausgleich umfasst. Sie können diese Methode auch verwenden, um Datenverkehr zwischen den Spokes über die NVAs zu senden.

Dieses Diagramm zeigt einen Hub und zwei Speichen. Der Hub enthält ein Gateway-Subnetz und ein NVA-Subnetz. Das Gateway-Subnetz enthält ein VPN- oder ExpressRoute-Gateway. Das NVA-Subnetz enthält einen internen Azure-Lastenausgleich und NVAs. Jede Speichen enthält einen App-Server. Spoke2 enthält eine Notiz, die wie folgt lautet: Spokeroutentabelle 0.0.0.0/0 nach 10.0.0.36 und Gatewayweiterleitung deaktivieren. Eingehender Datenverkehr fließt aus der lokalen Umgebung über das VPN- oder ExpressRoute-Gateway und dann den internen Azure Load Balancer zu den NVAs. Dieser Datenverkehr fließt dann in Spoke2 zum App-Server. Der Rückgabedatenverkehr fließt von diesem App-Server über den internen Azure Load Balancer zu den NVAs. Dieser Datenverkehr fließt dann über das VPN- oder ExpressRoute-Gateway zu einer lokalen Umgebung.

In den vorherigen Diagrammen weiß "Spoke1" nicht vom Funktionsumfang von "Spoke2". Daher sendet der 0.0.0.0/0 UDR Datenverkehr, der für Spoke2 vorgesehen ist, an den internen Azure-Load-Balancer der NVA.

Bei Datenverkehr zwischen lokalen Netzwerken und Azure oder zwischen virtuellen Azure-Computern wird die Datenverkehrssymmetrie durch das interne Azure-Lastenausgleichsmodul in single-NIC NVAs garantiert. Wenn beide Richtungen eines Datenverkehrsflusses denselben Azure Load Balancer durchlaufen, wählt der Load Balancer für beide Richtungen dieselbe NVA-Instanz aus. Wenn ein Dual-NIC NVA-Design über einen internen Lastenausgleich für jede Kommunikationsrichtung verfügt, stellt SNAT die Verkehrssymmetrie sicher. Das vorherige North-South Diagramm stellt ein Beispiel für diesen Entwurf bereit.

Bei diesem Entwurf müssen Dual-NIC-NVAs bestimmen, wohin Antworten für die Integritätsprüfungen des Lastenausgleichs gesendet werden sollen. Load Balancer verwendet immer die gleiche IP-Adresse wie die Quelle für die Integritätsprüfungen, d. h 168.63.129.16. Die NVA muss diese Gesundheitsprüfungsantworten über dieselbe Schnittstelle zurücksenden, über die sie empfangen wurden. Dieser Vorgang erfordert in der Regel mehrere Routingtabellen in einem Betriebssystem, da das zielbasierte Routing die Antworten über dieselbe NIC sendet.

Der Azure Load Balancer hat eine sehr gute Konvergenzzeit bei Ausfällen einzelner NVAs. Sie können Integritätstests alle fünf Sekunden senden, und es sind drei fehlgeschlagene Tests erforderlich, um eine Back-End-Instanz als nicht betriebsbereit zu erklären. Daher dauert es in der Regel 10 bis 15 Sekunden, bis der Azure-Load-Balancer den Datenverkehr zu einer anderen NVA-Instanz umleitet.

Dieses Setup unterstützt sowohl aktive als auch aktive/Standby-Konfigurationen. Bei Active/Standby-Konfigurationen müssen die NVA-Instanzen entweder einen TCP- oder UDP-Port oder einen HTTP-Endpunkt bereitstellen, der nur auf die Integritätssonden für das Lastenausgleichsmodul für die Instanz reagiert, die sich derzeit in der aktiven Rolle befindet.

Layer-7-Lastenausgleichsgeräte

Ein spezifisches Design für Sicherheitsgeräte ersetzt den öffentlichen Lastenausgleich von Azure durch einen Layer-7-Lastenausgleich wie das Azure-Anwendungsgateway, das als NVA selbst betrachtet werden kann.

In diesem Szenario benötigen die NVAs nur einen internen Lastenausgleich für den Datenverkehr von den Workload-Systemen. Dual-NIC-Geräte verwenden diesen Ansatz manchmal, um Routingprobleme mit den Integritätsprüfungen des Azure Load Balancer zu vermeiden. Dieses Design unterstützt nur die Layer-7-Protokolle, die vom Layer-7-Lastenausgleich unterstützt werden, was in der Regel HTTP und HTTPS ist.

Der NVA sollte eingehenden Datenverkehr für Protokolle verarbeiten, die vom Layer-7-Lastenausgleich nicht unterstützt werden. Das NVA kann auch den ausgehenden Datenverkehr verarbeiten. Weitere Informationen finden Sie unter Firewall und Anwendungsgateway für virtuelle Netzwerke.

Route Server

Route Server ist ein Dienst, der es einem NVA ermöglicht, über BGP mit softwaredefiniertem Azure-Netzwerk zu interagieren. NVAs erfahren, welche IP-Adresspräfixe in virtuellen Azure-Netzwerken vorhanden sind. Sie können auch Routen in die effektiven Routentabellen virtueller Computer in Azure einfügen.

Dieses Diagramm zeigt einen Hub und zwei Speichen. Der Hub enthält ein Gatewaysubnetz, ein NVA-Subnetz und ein Routingserver-Subnetz. Das Gateway-Subnetz enthält ein VPN- oder ExpressRoute-Gateway. Das NVA-Subnetz enthält zwei NVAs. Das Route Server-Subnetz enthält den Route Server. Jede Speichen enthält einen App-Server. Spoke2 enthält eine Notiz, die wie folgt lautet: effektive Spokerouten 0.0.0.0/0 nach 10.0.0.37 und 0.0.0.0/0 nach10.0.0.38. Eingehender Datenverkehr fließt vom öffentlichen Internet über den öffentlichen Azure-Lastenausgleich zu NVA1. Dieser Datenverkehr fließt dann in Spoke2 zum App-Server. Der Rückgabedatenverkehrfließt von diesem App-Server zum NVA1 und dann zum öffentlichen Internet. Die BGP-Adjazenz stellt eine Verbindung zwischen NVA1, NVA2 und dem Route Server her. NVA2 und Route Server sind über eBGP verbunden.

Im vorherigen Diagramm verbindet sich jede NVA-Instanz über BGP mit dem Route Server. Für diesen Entwurf ist keine Routentabelle in den Speichensubnetzen erforderlich, da Route Server die Routen programmiert, die die NVAs bewerben. Wenn zwei oder mehr Routen auf den virtuellen Azure-Computern programmiert sind, verwenden sie ein kostengleiches Routing mit mehreren Pfaden, um eine der NVA-Instanzen für jeden Datenverkehrsfluss auszuwählen. Daher müssen Sie SNAT in dieses Design einschließen, wenn Sie die Datenverkehrssymmetrie benötigen.

Diese Einfügemethode unterstützt die Konfigurationen aktiv/aktiv und aktiv/Standby. In der Konfiguration aktiv/aktiv kündigen alle NVAs dieselben Routen an den Route Server an. In der Konfiguration aktiv/Standby kündigt ein NVA Routen mit einem kürzeren autonomen Systempfad (AS-Pfad) als die anderen an. Route Server unterstützt maximal acht BGP-Adjacencies. Wenn Sie also einen Scale-Out-Cluster mit aktiven NVAs verwenden, unterstützt dieses Design maximal acht NVA-Instanzen.

Dieses Setup hat eine schnelle Konvergenzzeit. Die Keepalive- und Holdtime-Timer der BGP-Adjazenz beeinflussen die Konvergenzzeit. Route Server hat standardmäßig keepalive Timer auf 60 Sekunden festgelegt und Haltezeit-Timer auf 180 Sekunden festgelegt. Die NVAs können jedoch während der Einrichtung der BGP-Adjazenz niedrigere Timer aushandeln. Das Festlegen dieser Zeitgeber zu niedrig könnte zu BGP-Instfähigkeiten führen.

Dieses Design passt zu NVAs, die mit Dem Azure-Routing interagieren müssen. Beispiele sind SD-WAN oder IPsec NVAs, die in der Regel über eine gute BGP-Unterstützung verfügen. Diese NVAs müssen die Präfixe kennen lernen, die in virtuellen Azure-Netzwerken konfiguriert sind, oder bestimmte Routen über private ExpressRoute-Peerings bewerben. Diese Arten von Appliances sind in der Regel statusfrei, sodass die Symmetrie des Datenverkehrs kein Problem darstellt und SNAT nicht erforderlich ist.

Gatewaylastenausgleich

Gateway Load Balancer bietet eine Möglichkeit, NVAs in den Datenpfad einzufügen, ohne den Datenverkehr mithilfe von UDRs weiterleiten zu müssen. Für virtuelle Computer, die ihre Workloads über einen Azure-Lastenausgleich oder eine öffentliche IP-Adresse verfügbar machen, können Sie eingehenden und ausgehenden Datenverkehr transparent an einen Cluster von NVAs weiterleiten, die sich in einem anderen virtuellen Netzwerk befinden. Das folgende Diagramm zeigt den Pfad, dem Pakete für eingehenden Datenverkehr aus dem öffentlichen Internet folgen, wenn die Workloads die Anwendung über einen Azure-Lastenausgleich verfügbar machen.

Dieses Diagramm zeigt ein virtuelles NVA-Netzwerk und ein virtuelles App-Netzwerk. Das virtuelle NVA-Netzwerk enthält einen Gateway Load Balancer und NVAs. Das virtuelle App-Netzwerk enthält einen Webserver. Der Benutzerfluss geht vom Internet über einen öffentlichen Standard-Azure-Load-Balancer zum Webserver. Der von Gateway Load Balancer gesteuerte Datenfluss läuft vom öffentlichen Standard-Azure-Lastenausgleich zu Gateway Load Balancer und dann zu den NVAs. Dieser Datenfluss kehrt die Flussrichtung um und bewegt sich von den NVAs zum Gatewaylastenausgleich und dann zum öffentlichen standardmäßigen Azure Load Balancer.

Diese NVA-Injektionsmethode bietet die folgenden Vorteile:

• Für diese Methode ist SNAT nicht erforderlich, um die Datenverkehrssymmetrie zu gewährleisten.

• Sie können dieselben NVAs verwenden, um den Datenverkehr zu und von verschiedenen virtuellen Netzwerken zu inspizieren, was aus der NVA-Perspektive Mehrmandantenfähigkeit bietet.

• Peering virtueller Netzwerke ist zwischen dem virtuellen NVA-Netzwerk und den virtuellen Workload-Netzwerken nicht erforderlich, was die Konfiguration vereinfacht.

• UDRs sind im virtuellen Workloadnetzwerk nicht erforderlich, was auch die Konfiguration vereinfacht.

Sie können die Dienstinjektion über den Gatewaylastenausgleich für eingehenden Datenverkehr zu einem öffentlichen Azure Load Balancer, dessen Rückgabedatenverkehr und ausgehendem Datenverkehr von Azure verwenden. Ost-West Datenverkehr zwischen Azure-VMs kann den Gatewaylastenausgleich nicht für NVA-Injektion nutzen.

Im NVA-Cluster werde durch die Integritätsprüfungs des Azure Load Balancer Fehler in einzelnen NVA-Instanzen, was die Konvergenzzeit auf 10 bis 15 Sekunden verkürzt.

Dynamische öffentliche IP-Adresse und UDR-Verwaltung

Ziel dieses Designs ist es, eine Einrichtung zu haben, die ohne NVA-Redundanz funktioniert und geändert werden kann, wenn die NVA Ausfallzeiten erlebt. Das folgende Diagramm zeigt, wie eine öffentliche Azure-IP-Adresse einem aktiven NVA (NVA1 im Diagramm) zugeordnet ist. Die UDRs in den Spokes verwenden die IP-Adresse (10.0.0.37) des aktiven NVA als nächsten Hop.

Dieses Diagramm zeigt einen Hub und zwei Speichen. Der Hub enthält ein Gateway-Subnetz und ein NVA-Subnetz. Das Gateway-Subnetz enthält ein VPN- oder ExpressRoute-Gateway. Das NVA-Subnetz enthält zwei NVAs. NVA1 wird als aktiv bezeichnet, und NVA2 wird als Standby bezeichnet. Jede Speichen enthält einen App-Server. Spoke2 enthält eine Notiz, die wie folgt lautet: Spokeroutentabelle 0.0.0.0/0 nach 10.0.0.37 und Gatewayweiterleitung deaktivieren. Eingehender Datenverkehr fließt von internet zu NVA1 über eine öffentliche IP-Adresse. Dieser Datenverkehr fließt dann zu Spoke2. Der Rückgabedatenverkehr fließt von Spoke2 zu NVA1 und dann zum Internet.

Wenn das aktive NVA nicht mehr verfügbar ist, ruft das Standby-NVA die Azure-API auf, um entweder die öffentliche IP-Adresse und die Spoke-UDRs sich selbst zuzuordnen oder die private IP-Adresse zu übernehmen. Diese API-Aufrufe können mehrere Minuten dauern, um effektiv zu sein. Dieser Entwurf bietet die schlechteste Konvergenzzeit zwischen den Optionen in diesem Artikel.

Dieses Design unterstützt nur aktive/Standby-Konfigurationen, was zu Skalierbarkeitsproblemen führen kann. Wenn Sie die Bandbreite erhöhen müssen, die Ihre NVAs unterstützen, müssen Sie beide Instanzen hochskalieren.

Für dieses Design ist SNAT nicht erforderlich, um die Datenverkehrssymmetrie zu gewährleisten, da jeweils nur ein NVA aktiv ist.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• Keith Mayer - Deutschland | Principal Cloud Solution Architect
• Telmo Sampaio | Leitender Servicetechniker
• Jose Moreno | Leitender Ingenieur

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächster Schritt

• Umkreisnetzwerke

Zugehörige Ressource

• Implementieren eines sicheren Hybridnetzwerks mithilfe der Azure Firewall