jeśli mówisz o Hostie vSphere, możesz zobaczyć lub usłyszeć, jak ludzie nazywają go ESXi, a czasami ESX. Nie, ktoś nie po prostu upuścił i, była poprzednia wersja hypervisora vSphere o nazwie ESX. Można również usłyszeć ESX określany jako ESX classic lub ESX full form.
dzisiaj chcę rzucić okiem na ESX vs ESXi i zobaczyć, jaka jest różnica między nimi. Co ważniejsze, chcę przyjrzeć się niektórym powodom, dla których VMware zmieniło architekturę hiperwizora vSphere od 2009 roku.
w tym przewodniku
czym jest ESX? (Elastic Sky X)
zastanawiasz się co to jest ESX? ESX oznacza Elastic Sky X. ESX jest tym, co bare metal hypervisor VMware wszyscy znamy i kochamy został pierwotnie nazwany. To właśnie tam zaczęła się wirtualizacja.
na dzisiejszą lekcję historii VMware zaczniemy od ESX. ESX był tym, co VMware bare metal hypervisor był pierwotnie nazywany. Chociaż funkcjonalność dzisiejszych hostów ESXi jest bardzo podobna (choć znacznie bardziej zaawansowana) do ESX, istnieją pewne istotne różnice architektoniczne.
główną różnicą była konsola serwisowa ESX. Mój pierwszy wpis na blogu poświęcony był konsoli serwisowej ESX.
pomyśl o konsoli usług jako małej maszynie wirtualnej, która działa obok maszyn wirtualnych gości i zapewnia dostęp do hosta ESX. Konsola serwisowa pozwalała na logowanie się do ESX i wydawanie poleceń esxcfg w wierszu poleceń w celu skonfigurowania hosta.
oto bardzo prosty obraz tego, jak wyglądał:
oprócz dostępu do wiersza poleceń, można było pobrać i zainstalować w konsoli serwisowej ESX prawie każdego agenta, na przykład agentów do monitorowania sprzętu, tworzenia kopii zapasowych lub wszystkiego, co naprawdę chcesz.
w konsoli serwisowej mieszkali również agenci ESX management.
konsola serwisowa rozmawiała z Vmkernelem, który jest w zasadzie mózgiem twojego hosta ESX lub ESXi.
zanim porozmawiamy więcej o VMkernel, rzućmy okiem na to, co zmieniło się z ESXi.
co to jest ESXi?
zastanawiasz się co to jest ESXi? Jest to nowa generacja hypervisora VMware ESX. ESXi oznacza ESX integrated.
po utworzeniu ESXi, VMware zintegrował funkcjonalność konsoli usług z VMkernel, jak to:
ponownie jest to bardzo prosty schemat, ale można zobaczyć, jakie były główne zmiany, największe, które całkowicie eliminuje konsolę usług z architektury ESXi.
mimo, że oparłem się tej zmianie w tym czasie, miało to sens z wielu powodów. Pamiętaj, ESXi wyszedł z vSphere 4 w 2009 roku, który był boomem wirtualizacji. Wszyscy wirtualizowali wszystko w witrynie i uruchamiali swoje krytyczne obciążenia na ESX.
oto kilka powodów, dla których firma VMware mogła uznać tę zmianę za stosowną.
wydajność i stabilność dla VMware ESXi
podczas gdy konsola usługowa mogła używać tylko do 800 MB PAMIĘCI RAM (co może być znaczące w niektórych hostach ery 2009), nadal może siać spustoszenie z wydajnością i stabilnością.
pamiętasz tych agentów, o których rozmawialiśmy? Cóż, w tym przypadku zły agent może doprowadzić cię do zatrzymania ESX hosta, co nie było dobrą rzeczą.
zabezpieczenia hipernadzorcy VMware
powodem, dla którego tak łatwo było opracować i zainstalować agentów na konsoli serwisowej, było to, że konsola serwisowa była w zasadzie maszyną wirtualną linux siedzącą na hoście ESX z dostępem do VMkernel.
oznacza to, że konsola serwisowa musiała być załatana tak jak każdy inny system operacyjny Linux i była podatna na wszystko, co serwer Linuksowy.
widzisz problem z tym i uruchamianiem krytycznych obciążeń? Oczywiście.
pozbywając się tej „zarządzającej maszyny wirtualnej”, VMware było w stanie znacznie zmniejszyć powierzchnię ataku hipernadzorcy, co stawało się coraz ważniejsze, ponieważ adopcja rosła tak szybko.
uproszczenie zarządzania wirtualizacją
dzięki integracji tych funkcji zarządzania z VMkernel Architektura ESXi stała się znacznie prostsza niż ESX. Każdy, kto kiedykolwiek coś zaprojektował, może Ci powiedzieć, że im prościej, tym lepiej.
na przykład, zamiast instalowania zewnętrznego agenta do monitorowania sprzętu, VMware wprowadził Common Information Model lub CIM. Dzięki temu dane sprzętowe były łatwo widoczne na serwerze vCenter, a popularne platformy zarządzania sprzętem umożliwiały dostęp do nich za pośrednictwem vCenter.
aby uzyskać świetny przegląd CIM, sprawdź ten blog na stronie VMware. Pochodzi z 2011 roku i wspaniale wyjaśnia tę ogromną zmianę w architekturze ESX vs ESXi.
nie tylko uprościło to zarządzanie, ale zwiększyło stabilność i bezpieczeństwo ESXi jako całości.
co to jest VMkernel?
dużo mówiliśmy o VMkernel, który jest mózgiem ESXi.
chcę dać Ci prosty przegląd, abyś mógł naprawdę zacząć rozumieć jego możliwości.
jak mówiłem, VMkernel jest mózgiem operacji. Obsługuje takie rzeczy, jak planowanie zasobów i zarządzanie zasobami.
stosy sieci i pamięci są również w VMkernel, a sterowniki urządzeń hostów ESXi są również obsługiwane przez VMkernel.
czym są porty VMkernel?
w czasach ESX połączyliśmy się z naszymi hostami za pomocą specjalnego portu konsoli serwisowej. Zostało to skonfigurowane podczas procesu instalacji ESX, więc mogliśmy połączyć się z naszymi hostami, aby kontynuować konfigurację i zarządzanie nimi.
zaczynając od ESXi, skonfigurowaliśmy port VMkernel do zarządzania. Obecnie porty VMkernel służą o wiele więcej niż tylko zarządzaniu, ponieważ produkt vSphere ogromnie się rozwinął.
kiedy ESXi debiutowało, porty VMkernel były skonfigurowane do zarządzania, vMotion i pamięci masowej opartej na IP, jeśli jej używałeś. Jeśli konfigurujesz port VMkernel do przechowywania danych, po prostu nie mówisz vSphere, że jest on przeznaczony do specjalnego celu, takiego jak wymienione powyżej. Dzieje się tak dlatego, że przechodzi przez domyślny stos TCP/IP w vSphere.
porty VMkernel oczywiście istniały przed ESXi, ale jeśli nie używałeś pamięci IP lub vMotion (które na początku w to wierzyły lub nie były powszechnie używane), prawdopodobnie nigdy wcześniej nie skonfigurowałeś portu VMkernel.
dzisiaj, jak widać, istnieje wiele więcej aplikacji do korzystania z portów VMkernel. Więcej informacji na ich temat można znaleźć w Przewodniku VMkernel Networking guide firmy VMware.
ESX vs ESXi nie jest nawet porównaniem
kiedy ESXi pojawił się po raz pierwszy, wielu administratorów vSphere, w tym ja, miało obsesję na punkcie porównania ESX vs ESXi. Byliśmy tak przyzwyczajeni do konsoli serwisowej i naszych operacji vSphere wokół niej, że była to ogromna zmiana paradygmatu.
pamiętam, że specjalnie używałem narzędzia w konsoli serwisowej do zarządzania moim dużym środowiskiem ESX. Przed ESXi, rzeczy takie jak PowerCLI nie były powszechnie używane, ponieważ nie było powodu, po prostu używałeś poleceń esxcfg w konsoli serwisowej.
VMware Infrastructure Toolkit (dla Windows), lub VI Toolkit był poprzednikiem PowerCLI, został wydany dopiero w lipcu 2008 roku. Z perspektywy czasu można było zobaczyć, jak VMware ustawia scenę dla przyszłości swojej platformy, zapewnia wydajność, zabezpiecza bazę kodu i usprawnia zarządzanie.
spójrzmy prawdzie w oczy, ESX, ponieważ wiedzieliśmy, że nie będzie wspierał ciągłej trajektorii vSphere. Firma VMware musiała podjąć kroki, aby zabezpieczyć swój produkt na przyszłość.
w vSphere 4 VMware oferowało zarówno ESX, jak i ESXi, aby umożliwić klientom stopniową zmianę, ale gdy w 2011 roku pojawiła się vSphere 5, ESXi stało się hipernadzorcą VMware vSphere.
w tym czasie pojawiły się również narzędzia takie jak Auto Deploy, a PowerCLI zaczęły być doładowywane.
zauważyliśmy również, że coraz więcej funkcji pojawia się zarówno w ESXi, jak i vCenter. Jeśli porównałbyś ESX 4.1, który był ostatnią wersją ESX full form do ESXi 6.7, prawdopodobnie śmiałbyś się z ESX, gdyby twoja pierwsza wersja vSphere była 6 lub wyższa.
mimo, że była ona wyraźnie nowatorska, gdy pojawiła się po raz pierwszy, zmiany wprowadzone w architekturze ESX vs ESXi stworzyły scenę dla dalszego rozwoju i rozwoju vSphere. Bez tej zmiany na ESXi, po prostu nie bylibyśmy tam, gdzie jesteśmy dzisiaj.