K-NET s.c.

VMware vs Proxmox: Umarł król, niech żyje król

VMware: Umarł król

VMware, lider w dziedzinie wirtualizacji i infrastruktury chmurowej, ogłosił istotne zmiany w swojej strategii licencyjnej, przechodząc z tradycyjnych licencji wieczystych na model oparty na subskrypcji. Ta zmiana ma na celu nie tylko ułatwienie klientom dostępu do najnowszych innowacji i aktualizacji, ale także uproszczenie zarządzania portfolio produktów VMware. Aby zwiększyć elastyczność dla swoich użytkowników, VMware wprowadziło także opcję „Bring Your Own License”, która pozwala na bardziej elastyczne wdrożenia w zależności od indywidualnych potrzeb przedsiębiorstw. Te strategiczne zmiany są krokiem naprzód w dostosowywaniu oferty firmy do dynamicznie zmieniającego się rynku IT, z naciskiem na modele konsumpcji oparte na chmurze.

Więcej informacji na ten temat można znaleźć bezpośrednio na oficjalnym blogu VMware.

Proxmox: Niech żyje król

Artykuł na Techwrix przedstawia Proxmox VE jako ciekawą alternatywę dla rozwiązań VMware, skupiając się na jego otwartoźródłowym charakterze oraz wsparciu dla wirtualizacji zarówno KVM, jak i kontenerów LXC. Proxmox wyróżnia się dzięki swojemu interfejsowi webowemu, który ułatwia zarządzanie, funkcjom zapewniającym wysoką dostępność oraz wsparciu dla magazynowania zdefiniowanego programowo. Artykuł zwraca także uwagę na prostotę instalacji Proxmox i podaje praktyczne porady dotyczące jego optymalizacji. Ponadto, opisuje proces migracji z VMware do Proxmox, oferując użytkownikom wskazówki, jak przeprowadzić ten proces efektywnie.

Więcej szczegółów znajdziesz w oryginalnym artykule: Exploring Proxmox VE: A VMware Alternative.

G

Tagi: Proxmox, VMWare

Alpine Linux

Pierwszy raz Alpine Linux wpadł mi w oko przy okazji budowy maszyny wirtualnej w środowisku VMware ESXi kiedy miałem wskazać wybrany system z rodziny Linux z listy dostępnych opcji. Drugi raz nazwa ta przewinęła się przy okazji kontenerów LXC w Proxmoxie. Z czystej ciekawości zacząłem zastanawiać się dlaczego akurat ten system zasłużył sobie na to aby stać się jednym z wyborów w dojrzałych środowiskach wirtualizacyjnych. Po raz trzeci gdy przyjrzałem się uważniej gotowym kontenerom na Docker Hubie, gdzie bardzo duża ich część opierała się właśnie na Alpine jako systemie bazowym.

Jako zagorzały zwolennik Debiana, w myśl starego powiedzenia, że wszyscy zaczynają od różnych dystrybucji a kończą na Debianie, założyłem, że nic już nie może się zmienić w moich wyborach operatora systemowego. Byłem w dużym błędzie.

Od jakiegoś czasu Debian zaczął się zmieniać. Siła nawyków jest ogromna i ciężko było się przyzwyczaić do niektórych modyfikacji począwszy od trywialnej zmiany nazwy interfejsu sieciowego (gdzie się podziało stare dobre ETH0) a skończywszy na grubszych zmianach, które na przykład spowodowały przeniesienie i zmianę systemu logów (brrr…). Dlaczego zginęła początkowa prostota i przejrzysta logika w budowie systemu operacyjnego. Przecież Linuxem zainteresowałem się bo był dalece bardziej prosty w obłudze i logice działania niż Windows NT, którem zajmowałem się wówczas (sic!).

Tak czy inaczej jak tylko znalazłem chwilę czasu to postanowiłem wypróbować Apline, tym bardziej że Proxmox pozwala na wykreowanie kontenera tego typu w kilkanaście sekund. Wypróbowałem i oniemiałem. Zobaczyłem system jak za dawnych lat. Prosty, łatwy w obsłudze i niezwykle szybki.

Aby nie być gołosłownym przytaczam poniżej zestaw przykładowych podstawowych komend używanych tuż po instalacji świeżego systemu. Każdy może sam się domyślić do czego mogą służyć 🙂

apk update
apk update
apk add docker
rc-update add docker default
service docker start
reboot

Prawda, że wygląda bardzo znajomo? Wszystko co potrzebne można znaleźć wraz ze szczegółowym opisem na stronach Wiki projektu Alpine Linux Wiki. I dodatkowo powróciła nawet nazwa ETH0. Myślę, że ktoś kto miał do czynienia z tekstowym Debianem powinien być zadawolony.

Nie wiem jak długo zostanę przy projekcie Alpine Linux. Na razie trwa pierwsze młodzieńcze zauroczenia chociaż już pojawiły się pewne rysy. Ale o tym może innym razem.

MG

Tagi: Alpine, Linux

vCenter Converter powraca!

VMware ogłasza powrót jednego z najpopularniejszych produktów w katalogu – vCenter Converter. Wydano nową i ulepszoną wersję produktu, kompatybilną z vSphere 7.0 i ESXi 7.0. Opublikowana wersja koncentruje się głównie na poprawie stabilności i standardów bezpieczeństwa Konwertera oraz zachowaniu istniejącej funkcjonalności.

VMware vCenter Converter zachęca do wysłania informacji o chęci dołączenia do programu vCenter Converter Beta. Można skorzystać z tej możliwości, aby wpływać na przyszły kierunek rozwoju produktu. Jeśli nie masz dostępu do społeczności Beta, wystarczy, że odwiedzisz stronę rejestracji vCenter Converter BETA i przejdziesz do wypełnienia oraz wysłania formularza.

vCenter Converter jest bezpłatnym narzędziem zapewniającym możliwość konwersji maszyn wirtualnych działających na hiperwizorach innych dostawców oraz maszyn fizycznych na maszyny wirtualne VMware. Mowa wersja vCenter Converter obsługuje konwersję rozwiązań opartych na MS Hyper-V, konwersję pomiędzy formatami wirtualnymi VMware (Workstation, Fusion) oraz rekonfigurację maszyn wirtualnych VMware. vCenter Converter wspiera wirtualne stacje robocze działające pod kontrolą systemów Windows, Linux Ubuntu, CentOS, Red Hat Enterprise Linux.

Kolejne wydania będą wzbogacać listę obsługiwanych hyperwizorów, wersji vSphere, systemów operacyjnych i wirtualnych wersji sprzętu.

Link do oryginalnego komunikatu: https://blogs.vmware.com/code/2022/09/15/vcenter-converter-is-back/

MG

Tagi: Linux, serwer, VMWare, Windows, wirtualizacja

lovemyiot – pierwsze kroki w IoT

Czym jest IoT (ang. Internet of Things – Internet Rzeczy, stąd lovemyiot o czym za chwilę) nie trzeba tłumaczyć. Przynajmniej większości użytkowników sieci. Hasło stało się tak popularne, że nietrudno jest znaleźć w swoim otoczeniu, w pracy lub w domu urządzenie, które może mieć naklejkę z tym terminem. Niemniej trzeba jasno powiedzieć, że IoT to nie tylko inteligentna pralka czy lodówka, która łączy się z Internetem. Po dwuletnich doświadczeniachz z zagadnieniem mogę napisać, że jest to raczej filozofia komunikacji niż konkretne rozwiązanie albo technologia. Wiem, że brzmi to bardzo górnolotnie, ale trafnie oddaje obecny stan rzeczy.

Z IoT łączy się multum rozwiązań. Największy producenci z sektora IT postawili sobie za cel promowanie “nowych” produktów pod hasłem Internetu Rzeczy. Piszę o tym nie bez pewnej złośliwości bowiem sam spotkałem się z przypadkami, gdzie urządzenie sprzedawane do tej pory jako np. termometr IP do serwerowni stało się nagle węzłem IoT. I bardzo dobrze, jeśli założymy, że mamy właśnie do czynienia z filozofią.

Dając się ponieść zmianom postanwiliśmy wraz z kilkoma kolegami z branży zainteresować się IoT od strony komunikacji bezprzewodowej. Na samym początku odrzuciliśmy założenie o węzłach IoT posiadających niewyczerpane zasoby energetyczne i obliczeniowe, skłaniając się w stronę telemetrii (kolejny popularny termin) a więc małych węzełków-czujników z zasilaniem bateryjnym, których ilość idzie w setki albo nawet w tysiące. Bazując na takich podstawach skierowaliśmy się w stronę sieci LPWAN (ang. Low Power Wide Area Network) i dalej w konsekwencji w stronę technologii LoRa (ang. Long Range) oraz sieci LoRaWAN. Tak powstała dziedzina naszej działalności.

Kim jesteśmy? Obecnie jesteśmy nieformalnym stowarzyszeniem o nazwie lovemyiot, które ma zostać przekształcone w fundację wspierającą intensywny rozwój IoT w Polsce, uwzględniając w szczególności tematykę, o której wspomniałem w poprzednim akapicie. Zachęcam do śledzenia postępów działalności na stronach Facebook i Twitter:

Tweets by lovemyiot

MG@lovemyiot

Tagi: IoT, komunikacja globalna

Docker, Portainer i kłopoty z OpenProject

Techniki wirtualizacji są obecnie bardzo popularne. Począwszy od tych dostępnych na wyciągnięcie ręki dla każdego użytkownika, mam na myśli VirtualBox, a skończywszy na bardziej rozbudowanych typu VMware ESXi, czy QEMU. Te ostatnie wymagają już środowiska w pełni serwerowego i trochę zaawansowanej technicznie wiedzy (ale bez przesady). Z drugiej strony prężnie rozwija się technologia kontenerów wirtualizacyjnych typu Docker. Stają się one popularne głównie w środowisku programistów (koderów i developerów) bo pozwalają w łatwy sposób instalować całe środowiska z przygotowanych obrazów. Skraca to bardzo czas rozwoju oprogramowania, bo daje do ręki skonfigurowany gotowiec jak np. LAMP czyli Linux, Apache, MySQL, PHP/Python/Perl.

W tym wpisie chciałem się właśnie skupić się na apliakcji Docker. Wynika to głównie stąd, że jakiś czas temu realizowałem projekt polegający na zainstalowaniu całego środowiska developerskiego. Składały się na nie serwer z Debianem oraz 3 kontenery: GitLab, Nextcloud i OpenProject. Można powiedzieć solidne środowisko do pracy dla programistów. Całość została uruchomiona w sieci lokalnej, a każdy z wymienionych kontenerów był dostępny pod swoim własnym adresem IP oraz wewnętrzną nazwą domenową. Przy tej okazji chciałem podzielić się dwoma spostrzeżeniami, dotyczącymi problemów, których zrozumienie i dla których przygotowanie rozwiązania bardzo ułatwiło mi opracowanie rozwiązań. Jeden będzie dosyć ogólny, drugi zaś to przykład debugowania rozwiązania i zaaplikowania specyficznej łaty. Ale po kolei.

Środowiskiem kontenerów Dockera można zarządzać oczywiście za pomocą linii komend. Jednak jako alternatywe polecam gorąco projekt o nazwie Portainer. Instalowany jako jeden z pierwszych kontenerów naszego Dockera pozwoli w dosyć prosty i elegancki sposób zarządzać całością. Zwolenników aplikacji webowych ucieszy na pewno fakt, że jest to po prostu serwer, który udostępnia interfejs przeglądarkowy. Możemy zarządzać praktycznie wszystkimi potrzebnymi modułami w tym: kontenerami, obrazami, wolumenami i sieciami. Możliwości jest dużo więcej i najlepiej jest zainstalować to oprogramowanie samemu, żeby o tym się przekonać. Tym bardziej, że jest to łatwe jak instalacja każdego kontenera w Dockerze 🙂

Drugim problemem, bardziej złożonym, okazała się isntalacja OpenProject. Chciałbym o tym wspomnieć ponieważ jest to bardzo dobry przykład na to, z jakimi problememi można się spotkać używając Dockera. Sama instalacja z oficjalnego, przygotowanego przez autorów obrazu nie nastręcza większych żadnych trudności. Zaraz po uruchomieniu wszysko działa dobrze. Jednak z czasem, gdy będziemy musieli zrestartować cały serwer, a co za tym idzie swoje kontenery również, może się okazać, że OpenProject odmawia posłuszeństwa. Zamiast głównej strony serwisu natkniemy się na informacje o niedostępności. Po przeprowadzeniu wspomnianego na początku debugowania oraz sprawdzeniu stanu samego kontenera (który zachowuje się jak najbardziej poprawnie, czyli uruchamia się i nie zgłasza żadnych błędów) okazało się, że przyczyną jest zatrzymanie się serwera Apache. Niestety ręczne uruchamianie daemona również nie pomaga. Problem jest nieco głębszy i polega na tym, że w trakcie restartu kontenera zdarza się, że nie jest usuwany plik apache2.pid, co z punktu widzenia systemu oznacza, że Apache jak najbardziej działa cały czas (co nie jest prawdą). Rozwiązanie jest dosyć proste. Plik ten należy usunąć ręcznie, czyli:

• z poziomu Portainera (omówionego akapit wcześniej) połączyć się z konsolą,
• usunąć ręcznie plik PID: rm -f /var/run/apache2/apache2.pid,
• uruchomić Apache: /etc/init.d/apache2 start.

Powyższa sztuczka pokazuje, że pomimo iż oficjalne kontenery Dockera zazwyczaj działają bez zarzutu to czasami wymagana jest głębsza wiedza i grzebanie w czeluściach obrazu.

MG

 

Tagi: Docker, komendy, konfiguracja, linia poleceń, serwer, wirtualizacja

Jakość usług a dostawcy Internetu

Ze względu na swoją podstawową działalność (Politechnika Warszawska) brałem ostatnio udział w kursie dotyczącym m.in. pomiaru jakości usług w transmisji pakietowej. Akurat tak się złożyło, że na sali znaleźli się przedstawiciele operatorów telekomunikacyjnych oraz Urzędu Komunikacji Elektronicznej. Mniej więcej po połowie. Nim rozpoczął się sam wykład nagle wybuchła dyskusja na temat odpowiedzialności za jakość usługi. Z jednej strony operatorzy twierdzili, że mogą odpowiadać tylko za swój odcinek łącza na zasadzie gwarancji pasma od użytkownika do najbliższego routera brzegowego, z drugiej strony UKE, które twierdziło, że to za mało z punktu widzenia użytkownika.

Przyznam, że musiałem dobrze wszystko przemyśleć (dyskusja była dla mnie sporym zaskoczeniem) ale koniec końców doszedłem do generalnych wniosków – tutaj mój kij w mrowisko:

• Dlaczego operator nazywa często usługę np. ‘dostępem do Internetu’ skoro faktycznie jest to dostęp do najbliższego routera brzegowego?
• Dlaczego twierdzi, że jakość usługi spada bo użytkowników jest za dużo (czytaj – nie może za to brać odpowiedzialności). Czy to oznacza, że nie ma planowania zasobów? Przecież nawet w dostępie radiowym wiem ile mam maksymalnie dostępnego pasma, mogę zatem oszacować ilu użytkowników i z jaką jakością mogę obsłużyć.
• Dlaczego jest zawsze mowa np. o usłudze do 10Mbps. Przecież każdy administrator, który kiedykolwiek bawił się dzieleniem pasma wie, że gwarantuje się minimalną przepływność a jeśli są wolne zasoby to może ona szybować w górę.
• Dlaczego operatorzy zasłaniają się nieopłacalnością usługi z gwarancją pasma. Z mojego punktu widzenia, jeżeli postawiłem np. maszt z modemem radiowym to już poniosłem większość kosztów. Dołączając kolejnych użytkowników nie ponoszę specjalnie dużych kosztów.

Generalnie trzeba przyznać, że mamy do czynienia z piekłem transmisji z komutacją pakietów. W starej dobrej komutacji kanałów, gdzie użytkownik zajmował cały kanał na określony czas operator musiał planować ile może zestawić kanałów. Obecnie wydaje się, że można podłączyć dużo więcej użytkowników niż wynikałoby to z rozsądnego planowania (wiadomo – pakietówka, nie każdy zajmuje wiekszość nie zajmuje łącza przez 100% czasu).

Drugi wniosek to fakt, że użytkownik końcowy został pozostawiony samemu sobie i wydaje się, że nie ma żadnych narzędzi aby wiarygodnie zmierzyć sobie jakość dostępu do Internetu. O tym, że tak nie jest postaram się napisać w kolejnych wpisach.

MG

Tagi: komunikacja globalna, QoS