înregistrare Logare
Puncte:0
avatar Server

Separarea iSCSI de Ethernet prin VLAN

drapel in
Ray

Am configurat un mic cluster de câteva servere împreună cu un SAN. Serverele rulează Ubuntu 20.04 LTS.

Folosind instrucțiunile furnizate de furnizor (nu găsesc unde l-am citit înainte), ei au sugerat ca conexiunile iSCSI dintre SAN și servere să fie (sau poate că „trebuie să fie”?) separate de orice trafic ethernet. Din această cauză, am configurat două VLAN-uri pe switch-ul nostru -- unul pentru traficul iSCSI și unul pentru traficul ethernet între servere (pe care SAN-ul nu este activat).

Până acum, pare în regulă. Să presupunem că Ethernet este pe 172.16.100.XXX/24 și iSCSI este pe 172.16.200.XXX/24. Mai precis, adresele arată cam așa:

mașinărie ethernet iSCSI Și în afara ethernet-ului?
server 1 172.16.100.1 172.16.200.1 da
serverul 2 172.16.100.2 172.16.200.2 da
serverul 3 172.16.100.3 172.16.200.3 da
SAN N / A 172.16.200.4 Nu

Nu este surprinzător, pot ssh între servere folosind fie VLAN. Adică, de la serverul 2 la serverul 1, pot face oricare dintre următoarele:

  • ssh 172.16.100.1
  • ssh 172.16.200.1
  • ssh prin adresa IP vizibilă în exterior

Ceea ce mă îngrijorează este dacă ar trebui sau nu să separ mai bine traficul non-iSCSI de subrețeaua 172.16.200.X cu reguli de firewall, astfel încât portul 22 (ssh) să fie blocat pe toate serverele.

Nu mă îngrijorează invers -- SAN este doar pe VLAN 200. Nu știe că VLAN 100 există, așa că nu va trimite brusc trafic iSCSI pe acel VLAN.

Folosesc sistemul de fișiere Oracle Cluster care pare să folosească portul 7777 -- poate ar trebui să blochez toate porturile de pe VLAN, astfel încât să fie folosit doar portul 7777? Traficul Ethernet într-o rețea iSCSI creează probleme (fie lag sau erori?) de care ar trebui să fiu conștient?

Mulțumesc!

146
0 + 3
Michael Hampton avatar
drapel cz
Michael Hampton
Răspunde asta la întrebarea ta? [Amestecarea traficului SAN iSCSI cu traficul rețelei de bază, cer probleme?](https://serverfault.com/questions/272115/mixing-san-iscsi-traffic-with-core-network-traffic-am-i- cere-de-necazuri)
0
Răspunde
drapel in
Ray
@MichaelHampton Hmmmm... nu chiar. Răspunsurile par să fie despre a avea un comutator fizic separat pentru iSCSI. Sau că separarea celor două cu un VLAN va funcționa. Avem doar un comutator -- nu iau deciziile de a cumpăra un alt comutator, deși ar fi bine. Și, folosesc deja un VLAN. Bănuiesc că întrebarea mea este, trebuie să folosesc un firewall (adică, `ufw`) pentru a preveni traficul Ethernet pe VLAN-ul iSCSI (adică toate porturile cu excepția 7777, de exemplu)? Nu este necesar invers, deoarece SAN nu este nici măcar pe Ethernet VLAN.
0
Răspunde
joeqwerty avatar
drapel cv
joeqwerty
** Nu este surprinzător, pot ssh între servere folosind oricare VLAN.** - Hmmm... sunt conectate la ambele VLAN-uri. Puteți SSH de la o gazdă pe un VLAN non-iSCSI la un server folosind adresa IP iSCSI VLAN a serverului? Rulați o urmărire a rețelei pe un server și ssh la un alt server folosind adresa sa ip iSCSI ca țintă a sesiunii dvs. ssh. Care este interfața sursă și adresa IP a sesiunii dvs. ssh?
0
Răspunde
drapel in
Ray
@joeqwerty Vă mulțumim pentru urmărire! Mi-am actualizat întrebarea cu un tabel care (sper) explică mai bine problema mea. Nu sunt sigur dacă ajută... Care este comanda pentru a face o „urmăre a rețelei”? nu stiam cum sa fac asta...
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Presupun că „urma rețelei” este traceroute, de exemplu, `mtr`.
0
Răspunde
Puncte:1
Zac67 avatar Server
drapel ru
Zac67

Ceea ce mă îngrijorează este dacă ar trebui sau nu să separ mai bine traficul non-iSCSI de subrețeaua 172.16.200.X cu reguli de firewall, astfel încât portul 22 (ssh) să fie blocat pe toate serverele.

Dacă utilizați nume DNS pentru a vă conecta la alte servere și acestea se rezolvă la adresele LAN, ar trebui să fie bine. (Ca alternativă, puteți utiliza direct adresele IP LAN, desigur.)

daca tu într-adevăr doriți să dezactivați tot traficul non-iSCSI de pe SAN de care veți avea nevoie

  1. configurați toate serviciile pentru a se lega numai la adresele IP LAN
  2. utilizați firewall-uri locale pe servere pentru a filtra tot traficul nedorit
  3. utilizați ACL-urile pe porturile comutatorului iSCSI pentru a filtra tot traficul nedorit

Dacă filtrați, doar permiteți iSCSI și refuzați orice altceva este abordarea corectă.

Traficul Ethernet într-o rețea iSCSI creează probleme (fie lag sau erori?)

Principalul motiv pentru a separa traficul LAN și SAN este că doriți să vă asigurați că rețeaua de stocare nu se poate înfunda la toate evenimentele. Dacă ar face-o, ar provoca rapid erori I/O, provocând, la rândul său, pierderi de date și chiar corupție. Un volum (foarte) redus de trafic rătăcit nu este ceva de care să vă faceți griji cu adevărat.

Cu toate acestea, aș folosi abordarea ACL dacă legăturile de servicii (nr. 1) nu sunt practice sau dacă există alți administratori de server care iau lucrurile cu ușurință. De exemplu. actualizarea dinamică a DNS-ului vă pune foarte ușor IP-urile iSCSI în DNS și orice trafic inter-server poate ajunge rapid în SAN.

0 + 0
drapel in
Ray
Mulțumesc pentru explicația clară! Instrucțiunile vânzătorului SAN au fost să păstreze cele două traficuri separate, fără o explicație clară de ce. Voi vedea cum merg lucrurile; dacă performanța rețelei se degradează, voi analiza opțiunile pe care le-ați propus. Mulțumesc!
0
Răspunde
Zac67 avatar
drapel ru
Zac67
@Ray Bănuiesc că o parte a acestei recomandări este cauzată de comutatoarele care sunt posibile limitate în lățimea de bandă totală, astfel încât cadrele ar putea fi abandonate * înainte ca * limitele de legătură să fie atinse. Cu toate acestea, toate comutatoarele moderne sunt *neblocante*, adică. limitat doar de vitezele interfeței (sasiul modular mare exclus).
1
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.