Zarządzanie małym środowiskiem w ekonomicznej wersji licencyjnej wydaje się proste. Często faktycznie takie jest, ale pod warunkiem że administrator ma praktyczne doświadczenie w zarządzaniu takim środowiskiem. Prawidłowa konfiguracja klastra ułatwi rozwiązywanie problemów, które mogą nastąpić w czasie jego eksploatacji.

W poprzednim artykule na temat S2D – Storage Spaces Direct – dowiedzieliśmy się, jak działa hiperkonwergentne rozwiązanie oferowane przez Microsoft („IT Professional” 4/2019, s. 59). Po skonfigurowaniu środowiska sprawdzamy jego wydajność oraz przygotowujemy się do jego monitorowania.

Rozwój chmur publicznych i prywatnych oraz coraz większa popularność hiperkonwergencji nie byłyby możliwe bez rozwoju mniejszych projektów, będących fundamentem nowoczesnej infrastruktury IT. Przykładem realizacji trendu Software-Defined Storage jest GlusterFS.

Wśród komercyjnych rozwiązań do zarządzania wirtualizacją dominują produkty VMware vCenter Server oraz Microsoft System Center Virtual Machine Manager. Tymczasem podobne możliwości oferują darmowe rozwiązania, rozpowszechniane na licencji open source. W tej kategorii prym wiedzie oVirt, nadzorujący wirtualizację zbudowaną na bazie linuksowego Kernel-based Virtual Machine.

Kupno nowego systemu dyskowego wydaje się procesem prostym i szybkim, bo wybór na rynku jest ogromny. Problem pojawia się, gdy zaczynamy analizować potrzeby organizacji, aby kupiony sprzęt spełniał wymagania środowiska i nie przekroczył dostępnego budżetu.

NFS to protokół do współdzielenia przestrzeni dyskowej pomiędzy serwerami linuksowymi. Znajduje zastosowanie tam, gdzie wiele serwerów potrzebuje dostępu do wspólnego repozytorium plików. Może zatem stanowić ważny element środowisk aplikacyjnych wykorzystujących takie mechanizmy jak load balancing oraz failover. Jest także stosowany przy wirtualizacji serwerów – dostarcza hostom wspólną przestrzeń dyskową do składowania maszyn wirtualnych.

Z infrastruktury jako kodu (IaaC, Infrastructure as a Code) korzystają już inżynierowie systemów i administratorzy. Teraz, oprócz zarządzania konfiguracją serwerów i ich usług (za pomocą Ansible lub Puppet), jesteśmy w stanie zestawić całą sieć w chmurze, zanim uruchomimy jakiekolwiek serwery. Proces, jeśli dobrze zaplanowany i wdrożony, jest powtarzalny i przewidywalny. Dzięki temu możemy tak samo przygotować infrastrukturę dla różnych środowisk.

Analizując ustawienia stosowane przez największych dostawców chmury publicznej Microsoft Azure Database for MySQL oraz Amazon Relational Database Service (RDS), w poprzednim artykule opisaliśmy optymalną konfigurację MySQL. Tym razem na warsztat bierzemy bazę danych PostgreSQL.

Wbrew coraz powszechniejszej opinii systemy bazodanowe nie są jedynie repozytorium do przechowywania danych – w znakomitej większości przypadków są to skomplikowane byty o złożonym systemie operacyjnym. Baza danych Oracle nie tylko nie jest tu wyjątkiem, ale wręcz wyróżnia się ogromem opcji i możliwościami parametryzacji. Nietrudno więc o dużą liczbę półprawd, mitów i uogólnień, które znajdują się w internecie.

DSC jako platforma opiera się głównie na kodzie napisanym w PowerShellu. Kod ten można tworzyć na dwa sposoby – używając zasobów skryptowych lub klas. Od początku swego istnienia DSC wspiera zasoby skryptowe, które są w gruncie rzeczy modułami PowerShella wzbogaconymi o plik opisujący schemat zasobu (wykorzystuje on język Management Object Format – MOF). Od wersji piątej PowerShella zasoby możemy definiować jako klasy z odpowiednim atrybutem, dzięki czemu można uzyskać taki sam poziom ustrukturyzowania zasobu, jaki gwarantuje schemat w pliku MOF.