Dotaz: Napady a navrhy na storage pro virtualni stroje

[ok2zar]

Přílohy:

• Storage_on_virtual_current.png (53729 bytů)
• Storage_on_virtual.png (55666 bytů)
• Storage_on_virtual_planB.png (55630 bytů)

Zdravim vsechny.

Mam v kratke dobe jeste jeden dotaz, nebo spis prosbu o napad. Mam stroj, na nemz puvodne bezel nativne Wheezy a krom vseho dalsiho delal NFS a SAMBA server. Pred casem jsem udelal image a premigoraval to do virtualky, takze stavajici server bezi vesele dal, ale uz ve vertualnim zeleze. Pro urychleni celeho procesu jsem udelal (z meho pohledu) neciste reseni, kdy jsem dal virualce primy pristup k fyzickym diskum. Nemusel jsem tak nic menit na klientech.

Ted bych to chtel udelat tak nejak cisteji a napadlo me nekolik scenaru.

• Jeden by byl ten, ze nativni system by se staral o fyzicke disky a poskytoval je virtualce jako iSCSI a ta by je mohla poskytovat nadale tak, jak doposud. Tady je otazka, zda to neni zcela chybna uvaha.
• Druhy scenar je ten, ze NFS a SAMBU by poskytoval nativni Debian a vsechny virtualky by k tomu pristupovali budto pres NFS nebo SAMBU. Pro klienty v siti by to znamenalo prekonfigurovani. Dalsi problem je, ze nativni linux, ktery ma slouzit jen pro spousteni virtualnich stroju, by musel mit uzivatelske ucty pro pristup ke storage.

Pokud nekoho napada vyhodnejsi reseni, budu rad za jeho popis.

A jelikoz obrazek vyda za tisice slov, pokusim se sem nahrat stavajici stav i vyse popsane scenare.

Dekuji predem za rady.

Odpovědi

[NN]

Pokud mas ulozsite na stejnem fyzickem zeleze, nema pouziti iSCSI asi moc smysl. Primy pristup na disky se pouziva, nevidim v tom problem. Nekomplikuj si zivot a nech to tak, jak to je..

[Sten]

A co použít kontejner?

[ok2zar]

Nejak se nechytam.

[Sten]

Při kontejnerové virtualizaci (LXC, OpenVZ) má kontejner přímý přístup k diskům či souborovému systému na hostiteli, ale uživatelé, aplikace i síť jsou odděleny.

[ok2zar]

To zni zajimave. Urcite to prozkoumam.

[ok2zar]

Zkousel jsem jeste NBD (Network Block Device) a funguje to presne tak, jak bych si predstavoval. Jedine, co se mi zatim nepodarilo vyresit systematicky (ale jen jako work-around), je pripojeni NBD a primountovani filesystemu pomoci systemd. Systemd se snazi primountovat filesystem, ale dle logu neni v tu dobu pripojeno NBD a to dle sveho logu najizdi v dobe, kdy jeste nefunguje sit. A to presto, ze v zavislostech ma zadano, ze sit musi byt aktivni.

Ano, kdyz to udelam rucne, nebo pomoci rc.local a nebo jakykoliv dalsich obezlicek, tak to samozrejme maka. Urcite je to pro me jedna z moznosti. Kazdopadne si s tim jeste pohraji, aby to startovalo "ciste" pomoci systemd, kdyz uz ho mame namisto initu

[Aleš Kapica]

NBD je sice nejvýkonnější, protože jde v zásadě o jednoduchý protokol, ale má zásadní nedostatek, na kterém jsem se spálil už před šesti lety, kdy jsem řešil stejný problém podobně jako to chceš udělat teď ty - počti si. NBD protokol totiž nemá žádné ověřování jestli disk který mu nacpeš je ten který chce. To za prvé a za druhé - není stavěný na reconnect.