Przyspieszenie tworzenia AMI i ASG

Question

przy użyciu funkcji Ansible Tworzę AMI instancji ubuntu, a następnie za pomocą tego AMI tworzę konfigurację uruchamiania, a następnie aktualizuję i automatycznie skaluję grupę, czy są jakieś skróty, które mogę zastosować, aby przyspieszyć działanie ASG i AMI kroki, weź 10 minut +

Answer 1

Użyj AMI z opcją EBS zamiast z AMI z Store Instance Store. Z AWS docs:

  Amazon EBS-Backed    Amazon Instance Store-Backed 
Boot time Usually less than 1 minute Usually less than 5 minutes 

- http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device

Answer 2

zadałem podobne pytanie poprzez biletu AWS Wsparcia, tutaj było odpowiedzią: proces spożywania

Czas kiedy główny uruchomienie nowej instancji EC2 jest procesem rozruchowym systemu operacyjnego w instancji: mając mniej lub więcej grup bezpieczeństwa/ACL sieci, różna liczba kluczy SSH i ról związanych z instancją nie powinny mieć wymiernego wpływu w czasu potrzebnego do jej uruchomienia. Przez większość czasu, jaki zajmuje , instancja jest zużywana przez sam system operacyjny.

Mając to na uwadze, pozwala mi przejść przez niektóre z głównych elementów, które może zużywać najwięcej czasu, gdy instancja buty - dla wszystkich punktów Poniżej skupi się wyłącznie na systemie Linux z punktu EC2 z widzenia :

• lokalne wierzchowce systemu plików: jeśli instancja musi zamontować dużą ilość systemów plików, to doda trochę czasu do procesu rozruchu . W zależności od używanych typów systemów plików, może być konieczne przeprowadzenie sprawdzania okresowego co określoną liczbę dni - na przykład na Linux, w którym konieczne może być uruchamianie fsck na systemie plików ext4 co 90 dni (ten okres może się zmienić w zależności od twoje ustawienia), a system OS automatycznie uruchamia to sprawdzanie, gdy system plików jest zamontowany po uruchomieniu , jeśli wykryje, że okres został przekroczony. Jedna strategia dla uniemożliwiająca wykonanie tych sprawdzeń przed utworzeniem ampera AMI, którego użyjesz do uruchomienia nowych instancji, aby wszystkie instancje uruchomione z tego AMI miały ostatnio sprawdzone systemy plików , a Ty nie natrafisz na nieoczekiwane wykonanie polecenia fsck podczas uruchamiania instancji po raz pierwszy. W zależności od typu używanego systemu plików, może być możliwe całkowite wyłączenie tych okresowych sprawdzeń, , ale nie poleciłbym tego, ponieważ jest to konieczne do zachowania integralności systemu plików w czasie.

• Remote wierzchowce systemu plików: jeśli instancja musi zamontować dowolny zdalny system plików (na przykład udział EFS lub dowolny konwencjonalny akcji NFS), Twój proces rozruchu może zostać opóźnione w zależności od łączności sieciowej do udostępniania serwerów ten zdalny system plików. W najgorszym przypadku, jeśli serwer współużytkujący system plików jest w trybie offline, proces rozruchu zostanie przerwany, dopóki nie upłynie limit czasu tego połączenia. Jeśli instalujesz dowolne zdalne systemy plików po uruchomieniu swoich instancji, przed udostępnieniem instancji upewnij się, że udostępniane serwery są dostępne .

• Zwykłe skrypty inicjalizacyjne systemu operacyjnego: największa część czasu zużywanego przez proces rozruchowy zostanie podjęta przez uruchomienie usług OS . Istnieją dwa modele tego typu w systemie Linux: tradycyjny inicjator SystemV (który uruchamia usługi w sposób szeregowy, jeden po drugim) i stosunkowo nowy systemd (który jest w stanie uruchamiać usługi równolegle, a zatem zmniejszyć czas rozruchu w niektórych okolicznościach ). Które z nich będziesz używać, zależy od dystrybucji Linuksa , którą uruchamiasz w swoich instancjach. Na przykład, jeśli chcesz uruchomić serwer bazy danych, który może zająć dużo czasu za każdym razem, gdy uruchamiasz instancję , warto rozważyć systemd, ponieważ zezwoli on na na równoległe uruchamianie pozostałych niepowiązanych usług , jako o ile nie mają tego serwera bazy danych jako warunku wstępnego.

• Dane użytkownika i skrypty inicjujące chmurę: są wykonywane po zakończeniu zwykłych skryptów startowych systemu operacyjnego. Podobnie jak w przypadku poprzednich pozycji, użytkownik może chcieć sprawdzić, czy któryś z tych niestandardowych skryptów jest zoptymalizowany, aby zajmować jak najmniej czasu; to jest zalecane, aby przetestować niestandardowe skrypty danych użytkownika indywidualnie do zmierzyć czas przed dodaniem ich do nowej instancji uruchamiania, dzięki czemu może mieć lepszy pomysł na ich wpływ w ogólnym czasie uruchamiania instancji . Jeśli twoje skrypty pobierają zewnętrzne pliki z instancji z instancji (jeśli pobierzesz coś z wiadra S3, uruchom automatyczną aktualizację zainstalowanych pakietów ), powinieneś wziąć pod uwagę te rozważania dotyczące "Zdalnych instalacji systemów plików" Dotyczy produktów wymienionych powyżej: pozycja - upewnij się, że nie ma problemów z siecią, które mogłyby spowodować spowolnienie lub uniemożliwienie tego połączenia przez , ponieważ spowodowałoby to więcej czasu na całkowity proces uruchamiania instancji.

• Typ wystąpienia: typ instancji ma wpływ na czas potrzebny na zakończenie rozruchu systemu operacyjnego. W tych samych okolicznościach wystąpienie t2.large uruchomi się szybciej niż t2.nano, ponieważ ma więcej pamięci RAM, procesorów wirtualnych i większą liczbę kredytów procesora - dzięki którym system operacyjny może szybciej wykonywać rozruch . Ponadto, jeśli potrzebujesz odzyskać duże ilości danych w ramach procesu uruchamiania instancji, , możesz chcieć użyć ulepszonego trybu sieciowego i zoptymalizowanych pod EBS instancji , aby zapewnić najlepszą dostępną przepustowość dla swoich potrzeb; zobacz linki na końcu tego komunikatu, aby uzyskać więcej informacji na temat tego.

• EBS Typ woluminu: podobnie jak w przypadku typu instancji wydajność woluminów EBS jest również czynnikiem, który może mieć wpływ na ogólny czas uruchamiania czasu uruchamiania instancji. Jeśli Twoja instancja musi odczytać duże ilości danych podczas procesu rozruchu z woluminu sc1 (wolumin HDD o niskiej wydajności zaprojektowanej dla rzadko uzyskiwanych danych), proces rozruchu będzie wolniejszy niż w przypadku, gdy instancja odczyta te same dane z woluminu PIOPS o znacznie wyższej wydajności - jeśli Twój przypadek użycia zawiera scenariusz, w którym jesteś tym dotknięty, możesz chcieć przetestować różne typy głośności, aby wybrać ten, który lepiej pasuje do Twoich potrzeb, . Podobnie wpływ na wydajność rozruchu ma również rodzaj głównego woluminu instancji: , ponieważ we wszystkich przypadkach będzie trzeba odczytać z niego informacje.W większości przypadków domyślne woluminy SSD "a.k.a. gp2 EBS" są wystarczające, na przykład dla woluminów root .

Ostatecznie, czas potrzebny do uruchomienia nowej instancji zostanie ustalona uruchamiając odniesienia dla konkretnego przypadku użycia; Ogólne rozważania, o których wspomniałem powyżej, mogą pomóc w skróceniu tego czasu, ale , aby określić, które ustawienia są najlepsze dla twojego środowiska, musisz przetestować i dostroić każdy parametr, aż osiągniesz punkt , w którym czas uruchomienia odpowiada Twoim potrzebom.

Załączam kilka linków na końcu tej odpowiedzi, podając więcej informacji o przedmiotach, o których wspomniałem w tej odpowiedzi.

Mam nadzieję, że ta informacja była dla Ciebie przydatna. Daj mi znać, jeśli masz jakieś pytania na temat: .

Dzięki,

Powiązane linki: - EC2 rodzaje wystąpień: https://aws.amazon.com/ec2/instance-types/ - typy woluminów EBS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html - EBS zoptymalizowane instancje: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html - tips wydajności dla woluminów EBS: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html - Usprawnianie współpracy trybie on EC2 Linux instancje: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html