Anforderungen für die virtuelle vSRX-Firewall auf Microsoft Hyper-V
In diesem Abschnitt erhalten Sie einen Überblick über die Anforderungen für die Bereitstellung einer virtuellen vSRX-Firewall-Instanz auf Microsoft Hyper-V.
Softwareanforderungen
Tabelle 1 listet die Softwareanforderungen für die vSRX Virtual Firewall-Instanz auf Microsoft Hyper-V auf.
Nur die virtuelle Firewall vSRX small flavor wird auf Microsoft Hyper-V unterstützt. vSRX Virtual Firewall 3.0 Multi-CPU-Versionen werden auf Microsoft Hyper-V unterstützt.
Komponente |
Spezifikation |
|---|---|
Hypervisor-Unterstützung |
|
Speicher |
4 GB |
Festplattenspeicher |
16 GB (IDE- oder SCSI-Festplatten) |
vCPUs |
2 |
Virtuelle Netzwerkadapter |
8 Hyper-V-spezifische Netzwerkadapter |
Komponente |
Spezifikation |
|---|---|
Hypervisor-Unterstützung |
|
Speicher |
4 GB |
Festplattenspeicher |
18 GB (IDE) |
vCPUs |
2 |
Virtuelle Netzwerkadapter |
8 Hyper-V-spezifische Netzwerkadapter |
Ab Junos OS Version 19.1R1 unterstützt die virtuelle vSRX-Firewall 3.0-Instanz Gastbetriebssystem mit 2 vCPUs, 4 GB virtuellem RAM und 18 GB Speicherplatz auf Microsoft Hyper-V und Azure für eine verbesserte Leistung.
Hardwareanforderungen
Tabelle 3 listet die Hardwarespezifikationen für den Hostcomputer auf, auf dem die virtuelle vSRX-Firewall ausgeführt wird.
Komponente |
Spezifikation |
|---|---|
Größe des Hostspeichers |
Mindestens 4 GB |
Host-Prozessortyp |
x86- oder x64-basierter Multicore-Prozessor
Hinweis:
DPDK erfordert Intel Virtualization VT-x/VT-d-Unterstützung in der CPU. Weitere Informationen finden Sie unter Intel Virtualisierungstechnologie. |
Gigabit-Ethernet-Adapter (10/100/1000 BaseT) |
Emuliert den Multiport DEC 21140 10/100TX 100 MB Ethernet-Netzwerkadapter mit einem bis vier Netzwerkverbindungen. |
Best Practices zur Verbesserung der Leistung der virtuellen vSRX-Firewall
Lesen Sie die folgenden Vorgehensweisen, um die Leistung der virtuellen vSRX-Firewall zu verbessern.
NUMA-Knoten
Die x86-Serverarchitektur besteht aus mehreren Sockets und mehreren Cores in einem Socket. Jeder Socket verfügt außerdem über Speicher, der zur Speicherung von Paketen während der E/A-Übertragungen von der NIC zum Host verwendet wird. Um Pakete aus dem Speicher effizient zu lesen, sollten Sich Gastanwendungen und zugehörige Peripheriegeräte (wie die NIC) in einem einzigen Socket befinden. Eine Strafe ist mit spannenden CPU-Sockets für Speicherzugriffe verbunden, was zu einer nichtdeterministischen Leistung führen kann. Für die virtuelle Firewall vSRX empfehlen wir, dass sich alle vCPUs für die virtuelle vSRX-Firewall-VM im selben physischen, nicht uniformen Speicherzugriffsknoten (NUMA) befinden, um eine optimale Leistung zu gewährleisten.
Die Packet Forwarding Engine (PFE) der virtuellen vSRX-Firewall reagiert nicht mehr, wenn die NUMA-Knotentopologie im Hypervisor so konfiguriert ist, dass die vCPUs der Instanz über mehrere HOST-NUMA-Knoten verteilt werden. Die virtuelle Firewall vSRX erfordert, dass Sie sicherstellen, dass sich alle vCPUs auf demselben NUMA-Knoten befinden.
Wir empfehlen, die virtuelle Firewall-Instanz der vSRX an einen bestimmten NUMA-Knoten zu binden, indem Sie die NUMA-Knotenaffinität festlegen. Die NUMA-Knotenaffinität beschränkt die VM-Ressourcenplanung der virtuellen vSRX-Firewall auf den angegebenen NUMA-Knoten.
Schnittstellenzuordnung für virtuelle vSRX-Firewall auf Microsoft Hyper-V
Jeder für eine virtuelle vSRX-Firewall definierte Netzwerkadapter wird einer bestimmten Schnittstelle zugeordnet, je nachdem, ob es sich bei der virtuellen vSRX-Firewall-Instanz um eine eigenständige VM oder um ein Clusterpaar für hohe Verfügbarkeit handelt.
Ab Junos OS Version 15.1X49-D100 für die virtuelle vSRX-Firewall ist Unterstützung für Chassis-Clustering zur Bereitstellung von Netzwerkknotenredundanz nur auf Microsoft Hyper-V Server 2016 und höher verfügbar.
Beachten Sie Folgendes:
Im eigenständigen Modus:
fxp0 ist die Out-of-Band-Managementschnittstelle.
ge-0/0/0 ist die erste Schnittstelle für Datenverkehr (Umsatz).
Im Cluster-Modus:
fxp0 ist die Out-of-Band-Managementschnittstelle.
em0 ist die Cluster-Steuerungsverbindung für beide Knoten.
Jede der Datenverkehrsschnittstellen kann als Fabric-Links angegeben werden, z. B. ge-0/0 für fab0 auf Knoten 0 und ge-7/0/0 für fab1 auf Knoten 1.
Tabelle 4 zeigt die Schnittstellennamen und Zuordnungen für eine eigenständige virtuelle vSRX-Firewall-VM.
Netzwerkadapter |
Schnittstellenname in Junos OS |
|---|---|
1 |
fxp0 |
2 |
ge-0/0/0 |
3 |
ge-0/0/1 |
4 |
ge-0/0/2 |
5 |
ge-0/0/3 |
6 |
ge-0/0/4 |
7 |
ge-0/0/5 |
8 |
ge-0/0/6 |
Tabelle 5 zeigt die Schnittstellennamen und Zuordnungen für ein Paar virtueller vSRX-Firewall-VMs in einem Cluster (Knoten 0 und Knoten 1).
Netzwerkadapter |
Schnittstellenname in Junos OS |
|---|---|
1 |
fxp0 (Knoten 0 und 1) |
2 |
em0 (Knoten 0 und 1) |
3 |
ge-0/0/0 (Node 0)ge-7/0/0 (Knoten 1) |
4 |
ge-0/0/1 (Knoten 0)ge-7/0/1 (Knoten 1) |
5 |
ge-0/0/2 (Knoten 0)ge-7/0/2 (Knoten 1) |
6 |
ge-0/0/3 (Knoten 0)ge-7/0/3 (Knoten 1) |
7 |
ge-0/0/4 (Knoten 0)ge-7/0/4 (Knoten 1) |
8 |
ge-0/0/5 (Knoten 0)ge-7/0/5 (Knoten 1) |
Standardeinstellungen der virtuellen vSRX-Firewall auf Microsoft Hyper-V
Die virtuelle Firewall vSRX erfordert die folgenden grundlegenden Konfigurationseinstellungen:
Schnittstellen müssen IP-Adressen zugewiesen werden.
Schnittstellen müssen an Zonen gebunden sein.
Richtlinien müssen zwischen Zonen konfiguriert werden, um Datenverkehr zu erlauben oder zu verweigern.
Tabelle 6 listet die werksseitigen Einstellungen für Sicherheitsrichtlinien auf der virtuellen Firewall vSRX auf.
Quellzone |
Zielzone |
Richtlinien-Maßnahmen |
|---|---|---|
Vertrauen |
nicht vertrauenswürdig |
Genehmigung |
Vertrauen |
Vertrauen |
Genehmigung |
nicht vertrauenswürdig |
Vertrauen |
Verweigern |