Sziasztok
Adva van több XenServer host 1 gigabites hálón.
Az egyikben sok szabad HDD kapacitás van, így backup célre készítettem egy nagy VM-et, ahova többek között a többi hostről lemementem a xenserver VM-eket, egyéb backup fájlokat.
A gond az, hogy sok az 1 gigabit és limitálni szeretném, de nem működik rendesen.
XenSevernél az adott virtuális hálókártyánál kbyte/s mértékegységben lehet limitálni.
Ha 12 800 kbyte/s-re beállítom (100Mbit) és gigabites hálóról nyomom rá a backupot, nem korlátoz le 100Mbitre.
Ha erről a VM-ről küldök adatot, az 100Mbiten megy.
Némi kisérletezés után kijött, ha 300 Kbyte/s -re beállítom a QoS limitet, akkor 99~100Mbittel fogadja az adatokat, de küldeni csak 300 Kbyte/s-sel tudok.
Mi a magyarázat? Olyan, mintha a gigabről lőtt csomagokat nem tudná kellőképpen limitálni, csak ha nagyon csekély limitet állítok be. Ez visszatöltéskor viszont használhatatlanul lassú. Átlagos Internetes felhasználásnál jól működik a limit oda-vissza, de gigabittel lőve már nem.
Ha van valakinek egy egyszerű TC megoldása amit linux VM-ben beállítanék, az is jó lenne, hátha azzal megy. Gyakorlatilag az egyik linux guestben lévő 1 db eth0-ból 100Mbit uplinket kellene varázsolni, ami jelenleg a host gép miatt minden VM alatt 1Gbites.
Előre is köszönöm a segítséget.
- 6772 megtekintés
Hozzászólások
workaround TC nélkül: a linux guesten auto neg helyett fix 100fdx-re állítani az ethernet kártyát?
szerk: A Xenserveren a QoS csak kimenő forgalomra működik. Bejövőre nem. Vagyis a 300k/sec -es limit esetén a bejövő csomagokra adott válaszok sávszélességének korlátozása miatt áll be 100Mbit környékére a bejövő sávszélességed.
- A hozzászóláshoz be kell jelentkezni
a korlátozás tudtommal MINDÍG csak kimenő forgalomra működik.
Persze, a bejövő forgalom valahol mindíg kimenő :-)
tc-re nagyszerű példákat a lartc.org-on találsz.
re:workaround - mondjuk egy paravirt guest-en csinál a hálókártya egyáltalán nego-t?
- A hozzászóláshoz be kell jelentkezni
"mondjuk egy paravirt guest-en csinál a hálókártya egyáltalán nego-t?"
hát, most hogy mondod kipróbáltam, és Xen serveren belüli linuxon nem megy.
Egyébként meg minden ilyen dolog driver függő, lehet olyan virtualizált környezet és driver, ahol ilyen huncutságok is működhetnek.
"a korlátozás tudtommal MINDÍG csak kimenő forgalomra működik"
Ja valami ilyesmi rémlik nekem is. Mondjuk ha a VPS elé lehet rakni egy másik VPS-t ami a forgalom korlátozást csinálja, akkor a probléma megoldható.
- A hozzászóláshoz be kell jelentkezni
minek másik VPS? ott a dom0.
Ha a domU-hoz tartozó vif-en csinálsz korlátozást, mondjuk 10mbps-re, akkor A->B és B->A forgalom is korlátozásra kerül. A dolgot bonyolíthatod IPcím szerint is.
- A hozzászóláshoz be kell jelentkezni
XenServeren bem baxuk szét a dom0-t, mert előbb-utóbb rábaxunk...
(Citrix XenServerről beszélünk)
- A hozzászóláshoz be kell jelentkezni
Felesleges kézzel faragni és ráadásul hiábavaló is.
A legközelebbi újraindításnál / frissítés,bugfix telepítésénél
a beállítások fele automatikusan elveszik a másik részét pedig a patch törli :D
- A hozzászóláshoz be kell jelentkezni
ezt nem nekem akartad írni, én tudom... :)
- A hozzászóláshoz be kell jelentkezni
Inkabb ne.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
1. Le vagyon vésve a manualjába, hogy a qos limit csak és kizárólag kimenő forgalomra limitál.
Lásd itt: http://docs.vmd.citrix.com/XenServer/6.2.0/1.0/en_gb/reference.html#net…
2. a 300K-s beállításod magyarázata pedig az, hogy valószínűleg ekkora haránt-irányú forgalom keletkezett a TCP/IP válaszok miatt a 100M-ás bejövő forgalomnál.
3. Megoldás sajnos az, hogy a virtuális gépen belül limitálod le a szolgáltatást hálózati részen.
- A hozzászóláshoz be kell jelentkezni
Olyan nekromantikus ilyen kommenteket olvasgatni... :-)
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:
()=()
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni