eSputnik Private Cloud

eSputnik Private Cloud to wariant tej platformy wdrażany w dedykowanym, prywatnym środowisku chmurowym klienta.

Model wdrożenia eSputnik Private Cloud

eSputnik Private Cloud to wariant platformy eSputnik uruchamiany w dedykowanym, prywatnym środowisku chmurowym przygotowanym dla konkretnego klienta. Oznacza to, że środowisko działania platformy nie jest traktowane wyłącznie jako wspólna przestrzeń publicznej usługi dostępnej z jednej, współdzielonej infrastruktury. Kluczową cechą tego modelu jest wydzielenie zasobów oraz sposobu zarządzania środowiskiem zgodnie z ustaleniami wdrożeniowymi.

W praktyce należy odróżnić eSputnik Private Cloud od zwykłego programu instalowanego lokalnie na pojedynczym komputerze. Platforma działa jako system usług dostępnych przez sieć, a jej prawidłowe używanie zależy od komunikacji między przeglądarką lub aplikacjami integracyjnymi a środowiskiem chmurowym. Po stronie użytkownika istotne są więc między innymi poprawny adres usługi, rozwiązywanie nazw DNS, dostęp do wymaganych portów oraz prawidłowe uwierzytelnianie.

Warstwy techniczne prywatnego środowiska

Dedykowane środowisko chmurowe obejmuje zwykle kilka współpracujących warstw: zasoby obliczeniowe, pamięć masową, sieć, system operacyjny, usługi aplikacyjne oraz mechanizmy monitorowania. Sama nazwa Private Cloud nie wskazuje jednak konkretnego dostawcy infrastruktury, systemu operacyjnego ani technologii wirtualizacji. Nie należy dlatego przypisywać eSputnik Private Cloud określonego hypervisora, konkretnej dystrybucji Linuksa, kontenerów czy szczegółowej architektury baz danych bez potwierdzenia w dokumentacji danego wdrożenia.

Ważne jest także rozdzielenie płaszczyzny aplikacyjnej od infrastrukturalnej. Użytkownik korzysta z funkcji platformy, natomiast administrator środowiska odpowiada za dostępność hostów, połączenia sieciowe, certyfikaty TLS, kopie zapasowe, aktualizacje komponentów oraz obserwację obciążenia. Zakres odpowiedzialności może być podzielony między klienta, dostawcę platformy i operatora infrastruktury. Szczegóły takiego podziału wynikają z umowy i projektu wdrożenia, a nie z samego określenia Private Cloud.

Integracje, dostęp i diagnostyka połączeń

Wdrożenie eSputnik Private Cloud może wymagać połączenia platformy z innymi systemami używanymi w organizacji. Diagnostyka takiej komunikacji powinna rozpoczynać się od ustalenia, który element inicjuje żądanie, jaki adres docelowy jest używany i czy odpowiedź wraca do systemu wywołującego. Następnie sprawdza się rozwiązywanie DNS, trasę sieciową, reguły zapory, ważność certyfikatu oraz zgodność parametrów uwierzytelniania. Sam fakt, że strona otwiera się w przeglądarce, nie potwierdza poprawności wszystkich integracji.

Przy problemach z dostępem przydatne jest rozdzielenie błędów według warstwy. Brak odpowiedzi lub przekroczenie limitu czasu może wskazywać na problem z trasą, zaporą albo niedostępnością usługi. Błąd DNS oznacza problem z odnalezieniem adresu. Odrzucenie certyfikatu TLS może wynikać z niezgodnej nazwy hosta, nieważnego certyfikatu lub niepełnego łańcucha certyfikatów. Odpowiedź HTTP z kodem błędu może natomiast świadczyć o działaniu serwera, ale nieprawidłowej autoryzacji, konfiguracji żądania albo uprawnieniach. Do analizy potrzebne są dzienniki z właściwego komponentu i dokładny czas wystąpienia zdarzenia.

Utrzymanie środowiska eSputnik Private Cloud

Utrzymanie takiej platformy wymaga kontroli zarówno dostępności, jak i spójności konfiguracji. Warto dokumentować adresy usług, zależności między komponentami, używane certyfikaty, punkty integracji oraz osoby odpowiedzialne za poszczególne warstwy. Przy każdej zmianie powinno być jasne, czy dotyczy ona aplikacji eSputnik, sieci prywatnej, systemu nazw, zapory, systemu operacyjnego czy infrastruktury chmurowej. Taki podział ułatwia odtworzenie przyczyny awarii i ogranicza ryzyko wprowadzania zmian w niewłaściwym miejscu.

Diagnostyka komputera użytkownika może potwierdzić, czy problem wynika z lokalnej przeglądarki, konfiguracji sieciowej, certyfikatów zapisanych w systemie albo ograniczeń zapory. Nie wystarcza jednak do oceny stanu całego prywatnego środowiska platformy. W przypadku awarii po stronie usługi potrzebne są dane z monitoringu i logów infrastruktury oraz weryfikacja konfiguracji wdrożenia. Przydatne są również testy z kilku sieci i urządzeń, ponieważ pozwalają oddzielić usterkę lokalną od problemu dotyczącego całego środowiska.