Skip to main content
  • »
  • OPENSTACK CLI »
  • Jak uruchomić maszynę wirtualną z snapshot instance za pomocą OpenStack CLI na NSIS

Jak uruchomić maszynę wirtualną z snapshot instance za pomocą OpenStack CLI na NSIS

W tym artykule dowiesz się, jak utworzyć maszynę wirtualną z instance snapshot za pomocą klienta OpenStack CLI.

Wymagania wstępne

Nr 1 Konto

Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.

Nr 2 Klient OpenStack CLI

Musisz mieć zainstalowanego klienta OpenStack CLI. Powinien ci w tym pomóc jeden z poniższych artykułów:

Aby używać klienta OpenStack CLI do kontrolowania chmury NSIS, należy potwierdzić swoją tożsamość: Jak aktywować dostęp OpenStack CLI do chmury NSIS przy użyciu uwierzytelniania dwuskładnikowego

Nr 3 Pamięć Ephemeral a pamięć Persistent

Zapoznaj się z artykułem /datavolume/Ephemeral-vs-Persistent-storage-option-Create-New-Volume-on-NSIS, aby zrozumieć podstawową różnicę między ephemeral i persistent typami pamięci masowej w OpenStack.

Nr 4 Snapshot instance

Musisz mieć snapshot instance, z której zamierzasz utworzyć maszynę wirtualną. W tym artykule użyjemy przykładowego snapshot o nazwie my-instance-snapshot. Po uruchomieniu polecenia openstack image list ta instancja może wyglądać tal (tutaj jej nazwa została zaznaczona ciemnoniebieskim prostokątem):

../_images/start_vm_instance_snapshot_cli-01_creodias.png

Poniższe artykuły zawierają informacje o tym, jak utworzyć taki snapshot:

Należy pamiętać, że nazwa snapshot instance, która zostanie użyta w tym artykule, różni się od nazw używanych w wyżej wymienionych artykułach.

Niezależnie od tego, zajmiemy się obydwoma przypadkami:

  • snapshot instance korzystających z ehperemal pamięci masowej, jak również

  • snapshot instance korzystających z persistent pamięci masowej.

strong:Specjalne zasady dla migawek instancji korzystających z trwałej pamięci masowej

Jeśli snapshot używa persistent pamięci masowej, obowiązują specjalne zasady. Taki snapshot instance nie będzie miał własnego magazyn, ale sekcję metadanych, która zawiera listę snapshot volume, które zostały utworzone dla każdego z volume.

Niektóre lub wszystkie z tych snapshot volume teoretycznie mogą nie istnieć, ponieważ później mogły na przykład zostać usunięte.

Na przykład:

Snapshot volume reprezentującej dysk rozruchowy który jest niedostępny

W takim przypadku nie będzie można użyć migawki instancji do utworzenia maszyny wirtualnej.

Snapshot volume reprezentujący dysk rozruchowy który jest nadal obecny.

Będziesz mógł stworzyć nowa maszynę wirtualną uzywając instance snapshot. Jeśli dodatkowe volume będą podłączone do twojej VM tylko te które nadal mają odpowiadające im volume snapshot wspomniane w metadanych instance snapshot będą odtworzone.

Nr 5 Dostęp do utworzonej maszyny wirtualnej

Istnieją różne metody dostępu do maszyn wirtualnych, z których najpopularniejsze to SSH i konsola internetowa.

W przypadku SSH, podczas tworzenia maszyny wirtualnej z volume snapshot, może istnieć istnieje możliwość „wstrzyknięcia” klucza SSH do tworzonej maszyny. Niektóre systemy operacyjne są kompatybilne z tą funkcją, podczas gdy inne nie.

Jeśli nie jest możliwe dołączenie klucza SSH podczas tworzenia nowej instancji z określonej snapshot instance, upewnij się, że istnieje inny sposób dostępu do niej. Oprócz SSH i dostępu webowego, dostępne są także RDP, VNC, dostęp API, narzędzia webowe (Guacamole) i SFTP/FTP.

Przed rozpoczęciem odtwarzania instancji z snapshot musisz wiedzieć, jak uzyskać do niej dostęp.

Tak czy inaczej, zobacz następujące powiązane artykuły:

Jak dodać klucz SSH z konsoli internetowej Horizon na NSIS

Co zrobić, jeśli klucz SSH do maszyny wirtualnej nie został dodany lub został usunięty?

Jak uzyskać dostęp do maszyny wirtualnej z konsoli OpenStack na NSIS Cloud

Nr 6 Postępowanie zgodnie z artykułem referencyjnym dotyczącym tworzenia maszyny wirtualnej

Jako artykuł referencyjny wykorzystamy artykuł Jak utworzyć maszynę wirtualną przy użyciu klienta OpenStack CLI na chmurze NSIS Cloud, ale zmodyfikujemy niektóre z jego kroków.

Użyty tutaj snapshot instancji nie musi faktycznie zawierać systemu Linux — jeśli tak jest, możesz zignorować części artykułu referencyjnego specyficzne dla Linux.

Zbieranie informacji wykorzystywanych do tworzenia instancji

Kroki te są takie same bez względu na to, czy instancja korzysta z pamięci masowej epheremal czy z persistent.

W tym przykładzie utworzymy instancję o nazwie instance-from-snapshot. Jej źródłem jest instance snapshot o nazwie my-instance-snapshot, która jest już obecna w systemie.

Zbierz wymagane informacje, aby utworzyć polecenie openstack server create, jak wyjaśniono w artykule referencyjnym wspomnianym w wymaganiu wstępnym nr 6, ale wprowadź do przepływu pracy następujące modyfikacje:

Krok Wybierz obraz

W artykule referencyjnym krok Wybierz obraz wygląda następująco:

../_images/step-create-an-image.png

W tym artykule instancja powinna być widoczna obok innych obrazów, w tym:

  • obrazów, które są domyślnie dostępne w chmurze NSIS i/lub

  • obrazów przesłanych samodzielnie.

Można ją rozpoznać po nazwie lub identyfikatorze.

Wpisz ją jako wartość parametru –image w standardowy sposób.

W tym artykule nasza przykładowy snapshot ma identyfikator 56afe647-c49e-4f2d-892e-cd2c75f49ab3:

../_images/start_vm_instance_snapshot_cli-01_creodias.png

więc jest to parametr, którego będziemy używać:

--image 56afe647-c49e-4f2d-892e-cd2c75f49ab3

Zmiany w kroku Para kluczy

W kroku ** Para kluczy**, jeśli dana instalacja systemu operacyjnego obsługuje „wstrzykiwanie” w ten sposób klucza SSH, można wykonać ten krok tak, jak zostało to opisane w artykule referencyjnym.

Jeśli jednak instalacja nie obsługuje tego procesu, nie należy podawać parametru –key-name ani jego wartości.

Tworzenie instancji

Po zebraniu wszystkich niezbędnych informacji wykonaj odpowiednie polecenie openstack server create, jak wyjaśniono w artykułu referencyjnym z Wymagania wstępnego nr 6.

W naszym przykładzie to polecenie będzie wyglądać następująco (pamiętaj, aby użyć własnych parametrów).

openstack server create \
--image 56afe647-c49e-4f2d-892e-cd2c75f49ab3 \
--flavor eo1.small \
--network cloud_00734_1 \
--network eodata \
--security-group allow_ping_ssh_icmp_rdp \
--security-group default \
instance-from-snapshot
../_images/start_vm_instance_snapshot_cli-02_creodias.png

Aby sprawdzić, czy instancja została utworzona poprawnie, wykonaj polecenie openstack server list – dane wyjściowe powinny zawierać twoją instancję wraz z innymi instancjami, jeśli takie istnieją:

../_images/start_vm_instance_snapshot_cli-03_creodias.png

Jej Status powinien mieć wartość ACTIVE – twoja maszyna wirtualna powinna wtedy działać. Jeśli ma inny Status, taki jak BUILD, wykonaj ponownie polecenie openstack server list, być może wielokrotnie, aż status będzie miał wartość ACTIVE.

Jeśli Status ma wartość ERROR, oznacza to, że podczas tworzenia instancji wystąpił błąd. Badanie przyczyn takiego problemu wykracza poza zakres tego artykułu.

Co może pójść nie tak podczas odtwarzania instancji z migawki instancji?

Nieprawidłowe wersje obrazów (flavors)

Jeśli wskażesz flavor z niewystarczającymi zasobami, takimi jak pamięć masowa, może nie być możliwe utworzenie instancji lub może ona działać gorzej niż poprzednio lub w ogóle nie działać.

Nieprawidłowe lub brakujące sieci

Sieć lub podsieć, której chcesz użyć, może być nieobecna, usunięta, mieć zmienioną nazwę lub nawet nie została wybrana podczas procesu odtwarzania.

Jeśli instancja zostanie odtworzona bez połączenia sieciowego, może być niedostępna i/lub może nie być w stanie uzyskać dostępu do innych zasobów (takich jak na przykład bazy danych), których potrzebuje do prawidłowego działania.

Niedołączone volume

Podłączone volume zwykle nie są dołączane do instance snapshot. Więcej informacji można znaleźć w wymaganiu wstępnym nr 3.

Bez volume mogą być niedostępne dane, z którymi można operować, mogą być również niekompletne inne elementy.

Utrata metadanych lub danych konfiguracyjnych

Jeśli masz niestandardowe metadane, skrypty danych użytkownika, specjalne ustawienia konfiguracyjne itp.. mogą wymagać wykonania po przywróceniu instancji.

W przeciwnym razie aplikacje w takiej konfiguracji mogą zachowywać się nieprawidłowo lub nawet w ogóle się nie uruchamiać.

Zmienione adresy IP

Odtworzona instancja może mieć inny adres IP. Może to spowodować utratę połączenia i dostępu.

Można to rozpoznać po niedziałających łączach, zakłóceniach w komunikacji czy niedziałających usługach, jeśli opierają się na statycznych adresach IP.

Niewłaściwe kwoty i zasoby

Kwoty i limity dla nowej instancji mogą różnić się od kwot i limitów ze starej instancji.

Instancja nie zostanie utworzona, dopóki quoty nie zostaną ponownie dostosowane.

Niedziałające usługi zewnętrzne

Instancja może zależeć od zewnętrznych baz danych, zewnętrznych pamięci masowych lub innych rodzajów usług zewnętrznych i jest możliwe, że nie są one odtwarzane automatycznie wraz z instancją.

W takim przypadku usługi, z którymi chcesz używać instancji, nie będą dostępne lub będą działać nieprawidłowo.

Niespójny stan migawki

Zaleca się, aby najpierw zamknąć instancję, a dopiero potem utworzyć jej snapshot. Jeśli snapshot zostanie utworzony podczas działania instancji, niektóre dane mogą zostać utracone lub uszkodzone.

Doprowadzi to do błędów aplikacji, utraty danych lub niestabilności systemu.

Niekompatybilne środowiska

Instancja może działać nieprawidłowo lub nawet nie działać wcale, jeśli zawiera sterowniki i inne oprogramowanie, które jest niekompatybilne z bieżącym środowiskiem – flavorem i/lub chmurą.

Weryfikacja volume podczas korzystania z pamięci masowej persitent

Pomiń tę sekcję, jeśli twoja instancja używa pamięci masowej epheremal.

Jeśli instancja, z której utworzony snapshot, korzystała z pamięci masowej persistent, , dołączone do niej volume powinny zostać odtworzone podczas tworzenia instancji z tego snapshot. Sprawdzimy teraz, czy rzeczywiście tak się dzieje.

Zazwyczaj polecenie openstack server show służy do wyświetlania szczegółowych informacji o instancji. Tutaj użyjemy parametru -c, aby przyciąć jego dane wyjściowe, tak aby pokazywało tylko volume dołączone do maszyny wirtualnej.

Wykonaj poniższe polecenie, aby wyświetlić volume dołączone do instancji (zastąp f0734a16-60f5-4ce1-a774-2e86f7f2a6f6 identyfikatorem swojej instancji):

openstack server show f0734a16-60f5-4ce1-a774-2e86f7f2a6f6 -c volumes_attached
../_images/start_vm_instance_snapshot_cli-04_creodias.png

Zazwyczaj polecenie openstack server show służy do wyświetlania szczegółowych informacji o instancji. Tutaj ograniczamy jego dane wyjściowe tylko do dołączonych do niej volume.

Pole volumes_attached zawiera dwa volume oddzielone przecinkami.

W kolumnie Value dla każdego z dołączonych volume są widoczne dwie wartości oddzielone przecinkami.

Wartości w polu binarnym delete_on_termination oznaczają odpowiednio:

  • True: volume zostanie usunięty wraz z instancją, jeśli zostanie ona usunięta.

  • False: jeśli usuniesz instancję, ten volume nie zostanie automatycznie usunięty wraz z nią.

Pole id zawiera identyfikator volume.

W naszym przypadku żaden z dołączonych volume nie powinien zostać usunięty, ponieważ delete_on_termination w obu przypadkach ma wartość false.

Jeśli niektóre volume nie zostały odtworzone, może to oznaczać, że ich snapshot już nie istnieją.

Zwróć uwagę, że w tej części danych wyjściowych przecinek jest używany między właściwościami jednego volume, a nie między informacjami o różnych volume.

Należy również pamiętać, że snapshot instance nie zachowuje nazw volume.

Możesz zobaczyć szczegółowe informacje dotyczące każdego z tych volume, wykonując to polecenie (zastąp 3625f8fd-2837-4168-b361-ffa893a3ab17 identyfikatorem volume):

openstack volume show 3625f8fd-2837-4168-b361-ffa893a3ab17
../_images/start_vm_instance_snapshot_cli-05_creodias.png

Co można zrobić dalej?

Jeśli chcesz utworzyć maszynę wirtualną z snapshot instance przy użyciu Horizon Dashboard zamiast OpenStack CLI, zobacz artykuł Jak uruchomić maszynę wirtualną z instance snapshot przy użyciu dashboardu Horizon na NSIS Cloud