Új hozzászólás Aktív témák

• #12 joysefke veterán

  Új Válasz 2015-06-05 15:28:53 #12

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  joysefke

  veterán

  Ha valaki tud nekem esetleg hivatalos linked dobni a VSAN licensz struktúrájához, azt megköszönném, én semmit nem találtam. (nálunk is terítéken van a téma egy tesztrendszer keretében)

  J.

• #11 joysefke veterán hallador #10

  Új Válasz 2015-06-05 15:25:39 #11

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  joysefke

  veterán

  válasz hallador #10 üzenetére

  Erre a szimpla MS anyázásra miért is volt feltétlenül szükség?

• #8 joysefke veterán

  Új Válasz 2015-06-05 14:25:10 #8

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  joysefke

  veterán

  Javíts ki ha tévedek:

  Minden hoston két virtual switchet hoztam létre. Az első a külső forgalomért felelt, ahol minden host és a tárolásért felelős storage VM-ek is külön IP-t kaptak.

  Tehát ennek a switchnek voltak az uplinkjei és azokra állítottál be LACP-t

  Ezen zajlott a GlusterFS cluster, vCenter és a többi VM kommunikációja is, amiket VLAN-ok segítségével szeparáltam el.

  Tehát itt ment a management traffic, illetve storage traffic is, ha az adott hoston nem futott GlusterFS példány.

  A második vswitch-en a storage VM és a hostja kommunikált. Mivel a második switchre kötött hálózati csatolóknál mindenhol ugyanazokat az IP-ket (192.168.1.1 és .2) vettem fel, ezért a cluster konfigurációnál egyetlen közös tárolónak látta a gluster clustert a vSphere.

  Ennek a vSwitch-nek nyilván nem volt uplink-je (vagy legalábbis a fizikai hálózat nem switchelte a forgalmát), ezért futtathattál 4 darab VM-et ugyanazokkal az IP-kel.

  Ha a hoston futott GlusterFS, akkor az a storage eléréshez mindenképpen az ezen a vswitchen levő interfészét használta és a GlusterFS belső interfészéhez (192.168.1.1-2) ment.

  Ha a host olyan blokkokat akart olvasni, amelyek nem voltak rajta ezen a GlusterFS instance-on, akkor a hoston futó GlusterFS instance a másik hálózati interfészén keresztül lekérdezte a GlusterFS cluster megfelelő tagját

  Jól értem?

  Poor man's VSAN...

  J.

• #5 joysefke veterán

  Új Válasz 2015-06-05 14:05:09 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  joysefke

  veterán

  Több dolgot nem értek, ezek közül az egyik, hogy miért NFS-t használtál LACP-vel, ami ugye hash alapon fog terheléselosztást biztosítani kevés végpontnál valszeg elég kiszámíthatatlan és gyenge minőségben ezáltal jó eséllyel csak 1db GbE kártyát fog használni.

  Ahelyett hogy software-es iSCSI-t használtál volna több ethernet-interfésszel és port bindingel ezáltal lehetővé téve egy aktive-aktív (round robin) terheléselozstásos multipathingot. (feltéve hogy a Gluster képes erre. A FreeNAS9.3 például iSCSI-vel tuti képes erre.)

  Még egy ehhez kapcsolódó kérdés:
  LACP kapcsán egyszer source+dest mac hast írtál (vmware oldalon) másszor Etherchannel-t (switch oldalon). Miért nem IP hash (vmware oldalon)+Etherchannel(switch oldalon) -t komót használtál? (Igazából én mindig azt hittem, hogy ha switchen beállítod az Etherchannel, akkor onnantól muszáj IP Hast használnod vmware oldalon)

  J.

Új hozzászólás Aktív témák