Kategorie szkoleń | Egzaminy | Kontakt
  • 2
  • 6
  • 343

Odpowiedzi (2)

  • 1

Witam,

przedstawię Panu odpowiedź na przykładzie Hyper-V - myślę, że identycznie działa to pod KVM.

Otóż SR-IOV  jest "przybiciem" fizycznego interfejsu, np. sieciowego, do danej maszyny wirtualnej, dzięki temu omija się stos wirtualnego przełącznika, a co za tym idzie pasmo przełącznika/interfejsu nie jest kolejkowane i obsługiwane wraz z innymi wirtualkami, czyli szybciej i z mniejszym czasem dostępu odbywa się komunikacja.

Reasumując - o ile dla sieci/przełącznika wirtualnego będą zdefiniowane gotowe regułki filtrowania, o tyle przy SR-IOV należy mieć poprawkę, że traktujemy to, jako osobny interfejs. Zatem będzie szybciej, ale należy pamiętać o dodatkowej definicji np. Firewalla.

Odnośnie samej wydajności poprzez SR-IOV, uzyskujemy praktycznie takie same osiągi, jak przy niezwirtualizowanym środowisku.

  • Odpowiedział
  • @ | 23.03.2015
  • TRENER ALTKOM AKADEMII
Komentarze
O, dziękuję. A mogę jeszcze prosić o rozjaśnienie - jak w takiej sytuacji odbywa się komunikacja pomiędzy różnymi maszynami wirtualnymi będącymi na tym samym serwerze? Ruch dochodzi do switcha z różnymi mac i tam się jakoś zapętla? Czy też jest to mostkowane wewnątrz serwera? Jak w tym momencie jest realizowany podział na vlany? Przykładowo jak udostępnić maszynie wirtualnej A dostęp do vlanu 100, 101,102,103 z pvid 103, podczas gdy maszynie B vlany 100, 102 i 103, z pvid 102? Czy w takiej sytuacji karta sieciowa realizuje funkcje vlanów/przełączania ramek, czy też dzieje się to inaczej?
Skomentował : @ Andrzej_Dopierała ,23.03.2015
  • 83
  • 65
  • 169
  • 2

Część Pana pytania powinien wyjaśnić obrazek z tego linku (w zakresie realizacji SR-IOV):

http://blogs.technet.com/b/jhoward/archive/2012/03/12/everything-you-wanted-to-know-about-sr-iov-in-hyper-v-part-1.aspx

Ponadto na etapie definicji przełącznika wirtualnego można określić, do jakiego VLAN-a będzie on przynależał:

 

 

O ile maszyny wirtualne przy wykorzystaniu sieci wewnętrznej będą się komunikowały po wirtualnym switchu, to komunikację pomiędzy VLAN-ami, to już raczej routerem należy rozwiązać. Podobnie przy SR-IOV, który jak wspomniałem omija wirtualnego switcha.

  • Odpowiedział
  • @ | 24.03.2015
  • TRENER ALTKOM AKADEMII
Komentarze
W linuksie generalnie jest podobnie (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/chap-Virtualization_Host_Configuration_and_Guest_Installation_Guide-SR_IOV.html). Ale - pojawiają się kolejne pytania:
- oznaczenie interfejsu tagiem oznacza że ramki nietagowane wychodzące z gościa zostaną zatagowane przez sterownik VF i do switcha trafią już zatagowane. A co jeżeli byśmy chcieli dać do gośćia interfejs który na gośćiu będziemy tagować? Czy tagi "przejdą" aż do switcha i vice-versa? Jeżeli przejdą - jak zapewnić filtrowanie ruchu pomiędzy różnymi maszynami wirtualnymi/maszynami a switchem? Jedynie na gośćiu, czy też jest jakaś możliwość realizowacji tego na hoście? Ot - takie jak wspomniane wyżej - udostępnienie jednej maszynie np 3 vlanów tagowanych, a innej tylko 2 - tak by potencjalny włamywacz na drugiej maszynie do "trzeciego" vlanu nie miał dostępu.
- co z migracją live - jednym z "fajnych" ficzerów wirtualizacji jest migracja live maszyn. Czy jest jakaś możliwość wykorzystania jej podczas korzystania z sr-iov? Dokumentacja mówi że nie, ale - może jest jakiś "myk"?
Skomentował : @ Andrzej_Dopierała ,24.03.2015
  • 83
  • 65
  • 169
jeśli chodzi o "myk" i nazwijmy to "przechodniość" ramek tagowanych pod hyper-v - odsyłam do środowiska labowego - wtedy ew. nieudokumentowane sprawy można przetestować
z tym brakiem dostępu myślę że to sie właśnie realizuje by-default ;-) chyba że żle zrozumialem Pana pytanie ...
Skomentował : @ TRENER ALTKOM AKADEMII ,24.03.2015