Eksperymentalne kontenery w jądrze 2.6.24
- Dodano: 9 November 2007
- Wprowadził: aptak
- Komentarze: 24
Kontenery to technologia podobna do wirtualizacji. Szybsza, ale trudniejsza w implementacji. Eksperymentalna obsługa kontenerów w Linuksie pojawi się w wersji 2.6.24.
Wirtualizacja polega na uruchamianiu w ramach wirtualnej maszyny oddzielnej instancji systemu operacyjnego. Kontener uruchamiany jest w ramach jednego systemu (współdzielone jest jądro) i polega na sztucznym wydzieleniu grupy procesów, które nie mają dostępu do innych procesów uruchomionych w systemie. W BSD od dawna istnieje implementacja znana jako “jails”. Podobny system działa w Solarisie jako Solaris Containers. Dotychczas najlepszym sposobem uzyskania dostępu do kontenerów była instalacja narzędzia OpenVZ.
Jeśli dobrze pójdzie, zmieni się to wraz z wydaniem jądra 2.6.24, gdzie obsługa kontenerów pojawi się w wersji eksperymentalnej.
Więcej informacji: http://www.linuxworld.com
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
24 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
s/OpenVZ/Linux-vserver/
Jeśli już to s/OpenVZ/OpenVZ lub Linux-vserver/
Oba pełnią podobna rolę, z tym że OpenVZ lepiej sobie radzi z wirtualizacją sieci, dlatego chyba można powiedzieć że jest lepszy
Co to daje zwykłemu użytkownikowi na desktopie?
a co to ma do rzeczy?
A bo tyle się mówi o "Linuksie na desktopie", myślałem że może deweloperzy kernela coś robią w tym kierunku.
Lol, to się robi żałosne. Robią dużo w tym kierunku, ale nie tylko w tym, bo to system, w którym ma się odnaleźć nie tylko ZU, ale także każdy geek i nerd
A co robią w tym kierunku? Da się na tym teraz uruchomić popularny sprzęt, czy nadal trzeba sprawdzać przed kupnem "czy Linux to obsłuży"?
Troszkę wyobraźni
Bardzo zasadne pytanie. Tez chcialbym zeby mi ta sprawe troche bardziej naswietlono.
Na desktopie? Nic. Na serwerze daje bardzo duzo – najprosciej myslec o tym jak o Xenie, tylko bez zwiazanego z Xenem spadku wydajnosci. (No i bez kilku funkcji bez wiekszego znaczenia praktycznego – mozliwosci uruchomienia kilku roznych kerneli albo migracji vm-a z jednej fizycznej maszyny na druga.)
Oczywiscie zakladajac, ze te kontenery zostana zaimplementowane porzadnie i do konca. Troche to, niestety, potrwa.
hmm.. z tego co się orientuję, to będzie to działało podobnie jak jail w BSD, więc nie widzę problemu z przeniesieniem systemu z kontenera (jakiego vm-a?!) na inną maszynę
Nareszcie linux będzie to wspierał natywnie
@Wizard: Chodzi o przeniesienie bez przerywania dzialania. W Jailach tak nie zrobisz, w Solarisowych zonach afaik tez nie. Uslugi migruje sie troche inaczej, uruchamiajac druga i przekierowujac ruch, a potem wylaczajac ta pierwsza, juz nieuzywana.
Migracja vm-a z jednej fizycznej maszyny na druga bez znaczenia? Od razu widac, ze trasz-ponurak ma "duze" doswiadczenie w serwerowni. Znaczy, kiedys czytal o czyms takim jak serwer.
A mozliwosc uruchomienia innego kernela, czyli np. Windows, rowniez nie ma znaczenia praktycznego…
trasz – jestes prawdziwym "szpecyalista" od wszystkiego, na kazdy temat masz cos do powiedzenia. A ze nie zawsze zgodnie z prawda, coz, taka rola trolla.
Migracja jest akurat dosc znaczaca. OpenVZ i VServer to maja, wiec kontenery pewnie tez beda dawaly taka mozliwosc (kiedy juz beda nadawaly sie do uzytku).
Co do mozliwosci uruchomienia innego kernela to raczej juz kwestia tego do czego potrzebujesz wirtualek. Dla mnie nie ma znaczenia
, ale sporo ludzi korzysta z Xena wlasnie dlatego ze daje taka mozliwosc, oczywiscie cena za to jest wiekszy spadek wydajnosci, ale cos za cos.
@mangoo: W praktyce migruje sie usluge. Migracja calego VM-a nie jest do tego potrzebna. Moglaby byc _przydatna_, gdyby dzialala tak, jak reklamuja. A z tym jest na tyle roznie, ze poki co nie jest.
Do uruchomienia Windows potrzebna jest pelna wirtualizacja, a nie Xen. (Pomijam, ze do Xena wrzucono rzeczy, ktore nie sa z nim jakos mocno koncepcyjnie zwiazane, jak kvm).
@trasz: znowu popisujesz sie swoja niewiedza, brawo.
Twoja praktyka co do tego, co sie migruje, a co nie, jest rownie wielka, co twoja wiedza o serwerach (cos gdzies przeczytales o tym, co to jest serwer, ale jakby nie zrozumiales).
No, a skoro jestes na tyle oblatany w temacie wirtualizacji, to moze wytlumaczylbys, co miales na mysli mowiac "Moglaby byc _przydatna_, gdyby dzialala tak, jak reklamuja. A z tym jest na tyle roznie, ze poki co nie jest."? Bo widac ze nie masz pojecia o temacie, a trollujesz i bzdurzysz, jak zwykle zreszta.
Owszem, do uruchomienia Windows jest potrzebna pelna wirtualizacja, i ta umozliwia wlasnie Xen (obok parawirtualizacji).
I do Xena nie wrzucono KVM, ani na odwrot; to sa dwa odrebne projekty.
@mangoo: Mozesz podac przyklad sytuacji, gdy migracja calego VM-a Xen-em sprawdza sie lepiej, niz migracja "po ludzku", przekierowujac ruch?
Odnosnie dzialania zgodnie z reklama – problemy sa w dwoch miejscach. Po pierwsze, kwestia przerywania dzialania VM-a podczas migracji. Po drugie, kwestia IP i ogolnie lacznosci z siecia. Poczytaj, obejrzyj, zamiast slepo wierzyc w reklamowki RedHata. Nawiasem mowiac, swoj brak argumentow moglbys ukrywac bardziej elegancko niz pobredzajac na temat braku pojecia o temacie adwersarza. ;->
Realizacja pelnej wirtualizacji Xenem to wlasnie wrzucenie do niego rzeczy, ktora nie jest z nim mocno koncepcyjnie zwiazana.
mangoo: autorytatywnie wypowiadasz sie o czyjesc wiedzy na podstawie kilku jego komentarzy? co wiecej – robisz to w bardzo arogancki sposob (tak jak zazwyczaj ja
).
btw. dlatego "w praktyce migruje sie usluge", miast calego vmstate, bo jest to zagadnienie mniej skomplikowane i od wielu, wielu lat stosowane. moze i przenoszenie calego vm wydaje sie byc atrakcyjniejsze, ale w wiekszosci zastosowan nie potrzebne/nie potrzebnie zwiekszajace koszta wdrozenia/implementacji.
@jellonek: tak, autorytatywnie wypowiadam sie na temat wiedzy trasza, vel Ponure Zacietrzewienie znanego na innych listach – pierwszy raz czytasz wypociny tego trolla?
Migracja uslugi na inny serwer, i migracja wirtualnej maszyny na inny fizyczny serwer to dwa rozne zagadnienia, i bledem jest zakladac, ze to to samo.
@trasz:
> Odnosnie dzialania zgodnie z reklama – problemy sa w dwoch
> miejscach. Po pierwsze, kwestia przerywania dzialania VM-a
> podczas migracji.
Slyszales o czym takim jak live migration? Z tego co piszesz, wynika ze nie slyszales.
> Po drugie, kwestia IP i ogolnie lacznosci z siecia.
> Poczytaj, obejrzyj, zamiast slepo wierzyc w reklamowki
> RedHata.
Tzn. ile twoim zdaniem trwa "brak lacznosci" z siecia? Bo skoro tak sie na tym znasz, to powinienes nam zaraz napisac.
> Nawiasem mowiac, swoj brak argumentow moglbys ukrywac
> bardziej elegancko niz pobredzajac na temat braku pojecia
> o temacie adwersarza. ;->
Wiesz, czytalem wiele razy twoje "argu-męty", tak wiec to, ze tak pisze, nie jest jedynie na podstawie twoich postow w tym watku.
> Realizacja pelnej wirtualizacji Xenem to wlasnie
> wrzucenie do niego rzeczy, ktora nie jest z nim mocno
> koncepcyjnie zwiazana.
Uhm, juz raz pisales, ze do Xena wrzucono np. KVM, co jest oczywiscie nieprawda – Xen robil pelna wirtualizacje na dlugo przed tym, nim powstal KVM. Do Xena nie wrzucono KVM, jak to pisales.
Napisz jeszcze cos ciekawego, ale tym razem postaraj sie, zeby to bylo bardziej "koncepcyjnie zwiazane" z tematem.
Wbrew pozorom trochę daje. Może nie wszystkie cechy kontenerów ale część ich funkcjonalności na pewno. W szczególności Control Groups, o których wspomniałem już w innym kontenerze. Można sobie wyobrazić, że dzięki nim można by grupować pewne procesy wg zadań i wydzielać im zasoby tak żeby nie przeszkadzały w normalnej pracy (np jakaś kompilacja w tle). Ponadto kontenery mogą również używane jako narzędzie bezpieczeństwa a to na desktopach również jest istotne.
Kontenery są nie tylko eksperymentalne ale i zupełnie niekompletne. W jądrze 2.6.24 pojawi się dopiero pierwszy kawałek układanki, nazwany Control Groups oraz trochę koncepcyjnych systemów namespace-ów. Największym problemem
Control Groups działa już bardzo ładnie, można ich używać do rzeczy innych niż kontenery (w tej chwili istnieją m.in. użyteczne "moduły" do CPUSets i CPU accounting ale Control Groups można również użyć razem z nowym planistą CFS).
Największym problemem jest to iż nie da się dokończyć prac nad kontenerami bez zmian API. Jednym z problemów jest to, że do tej pory PID był unikalny w całym systemie i można było na nim polegać odwołując się do procesów. Po wprowadzeniu process namespace-ów nie jest to już prawdą i w całym jądrze trzeba zmienić kod odwołujący się bezpośrednio do PID-ów. Ponadto należy zmienić wywołanie systemowe "clone" (jedno z najważniejszych w systemie) lub dodać inne.
To tylko kilka z wielu problemów do rozwiązania więc zanim zacznie to działać na poziomie choćby BSD Jails, nie wspominając o OpenVZ/Linux-VServer, poczekać będzie trzeba jeszcze pewnie kilka wersji jądra.
Ludzie, ale wy nadęci czasem jesteście. Normalnie nie da się pogadać bez primitywnego stawiania się nad innymi na siłę.
A świstak dalej zawija sreberka i nie ma pojęcia o tym, że są z innej fabryki…