Богдан Стефанюк

Заметки о программировании, путешествиях и плёнке.
Обо мне  •  Список заметок  •  Плёнка

AWS Cloud Practitioner

На днях пополнил коллекцию сертификатов еще одним — AWS Cloud Practitioner.

К AWS присматривался давно, на текущий момент это самое популярное облако. C Нового года я работаю на новом проекте, который активно использует AWS. Это стало дополнительным мотиватором, чтобы разобраться с тем как всё устроено.

В качестве своего рода чекпоинта решил получить сертификат.

Также ко мне присоединился мой друг вместе, с которым начали активно готовиться. Сразу хочу отметить, что вдвоём готовиться намного эффективнее. В какой-то момент у нас проснулась небольшая гонка и не хотелось отставать друг от друга. Ещё мы пару раз собирались и активно задавали друг другу вопросы по AWS, что как мне кажется, было самым эффективным при подготовке.

Источники для подготовки:

Сам экзамен проходили в офлайне, что, как по мне, намного удобнее, чем в онлайне.

Балансировка нагрузки

Рано или поздно наступает момент, когда приложение начинает не справляться с нагрузкой и мы решаем горизонтально масштабировать нашу систему. Тогда возникает вопрос: как распределить запросы между несколькими машинами?

Для решения этой проблемы используют балансировщики нагрузки. С помощью набора алгоритмов они позволяют равномерно распределить нагрузку на сервера. Зачастую представлены в виде софтверного решения, реже как отдельные устройства.

Помимо распределения нагрузки, балансировщики также выполняют дополнительные задачи, такие как обнаружение служб и проверка работоспособности. Иногда они работают в качестве API Gateway для маршрутизации трафика или его троттлинга. Например, отправлять запросы по специфичному URL на какой-то конкретный сервис и не давать пользователям делать больше указанного порога запросов в секунду.

Обнаружение служб

Это процесс, который позволяет определить набор сервером, на которые можно отправлять запросы. Для реализации этого подхода можно использовать несколько способов:

  • Файлы конфигурации.
  • DNS
  • Zookeper, Consul и т. д.

Проверка работоспособности

Проверки работоспособности позволяют понять, какие сервера сейчас работают и могут обрабатывать запросы. Сами проверки деляться на два типа: активные и пассивные.

В пассивном режиме балансировщик наблюдает за основным потоком запросов и за тем как бэкенд на них отвечает. Например, он может решить что  сервер нерабочий, если он несколько раз подряд отвечает 503 статус кодом.

В активном режиме балансировщик периодически делает запросы на специальный эндпоинт, который проверяет состояние приложения. Их также можно разделить на несколько типов: liveness и readiness

Алгоритмы балансировки нагрузки

Все современные балансировщики имеют поддержку множества алгоритмов, которые позволяют оптимально распределить запросы. Самих алгоритмов есть огромное множество, но основных всего несколько:

  • DNS
  • Sticky Session
  • Round Robin
  • Weighted Round Robin
  • Least Connection
  • IP Hash

DNS
Самый простой способ распределить запросы это использовать DNS, он позволяет работать клиентам с несколькими серверами и повысить их доступность.  Для этого достаточно зарегистрировать несколько серверов на одно доменное имя. Когда клиент запрашивает IP адрес, DNS возвращает список адресов серверов, который каждый раз начинается с другого адреса. Такой подход похож на работу алгоритма Round Robin.

Проблема заключается в том, что DNS запросы обычно кэшируются в браузере пользователя или на уровне операционной системы. Из-за такого поведения пользователь может обращяться к неработающему серверу. Даже если оперативно удалить адрес упавшего сервера из списка, может пройти время пока DNS записи реплицируются на другие сервера и пока кэш пользователя инвалидируется.

Round Robin
Самый простой алгоритм. Балансировщик держит обычную очередь из серверов. Первый сервер в очереди обрабатывает запрос и помещается в конец очереди и так по кругу. Таким образом сервера равномерно нагружены.

Алгоритм отлично походит когда сервера в пуле имеют одинаковую мощность и время обработки запросов.

Weighted Round Robin
Тот же round robin, но имеет дополнительное свойство — вес сервера. С его помощью мы можем указать балансировщику сколько трафика отправлять на тот или иной сервер. Так сервера помощнее будут иметь больший вес и соответственно обрабатывать больше запросов чем другие сервера.

Least Connections
В основе алгоритма лежит очередь с приоритетом, которая отсортирована по количеству активных пользователей, где первый сервер имеет наименьшее количество соединений. Такой способ отлично подходит для систем где много активных соединений, например стриминг сервис или онлайн чат.

Алгоритм можно улучшить и учитывать не только количество соединений, но и среднее время. Тогда первым в списке будет сервер с наименьшим количеством подключений и наименьшим временем ответа. Такой алгоритм называется Least Response Time. Такой способ позволяет выровнять нагрузку если сервера отвечают с разной скоростью.

Hash
Такой способ использует в своей основе механизм хеширования. Он позволяет распределить запросы на основе хеша, для которого обычно используется IP адрес или URL. В таком случае запросы от одного и того же IP будут отправлены на один и тот же сервер. Тоже самое касается URL. Такой алгоритм обычно используют, когда сервер хранит какие-то локальные данные, которые нужны для ответа.

Примеры софтверных балансировщиков

  • HAProxy
  • nginx
  • AWS Route 53
  • AWS Elastic Load Balancer

Дополнительная информация

  • The power of two random choices. Автор предлагает отказаться от централизованной балансировки нагрузки и использовать балансировку на стороне клиента. Для этого информации и загруженности серверов сохраняется в каком-то кэше, который время от времени обновляется. Сами же клиенты будут случайным образом выбирать два сервера и отправлять запрос на менее загруженных из двух. Такой подход позволяет оптимально распределять нагрузку и избавиться от центрального балансировщика.
  • Introduction to modern network load balancing and proxying. Хорошая статья в которой описаны способы использования балансировщиков нагрузки и в чем разница между L4 и L7 балансировкой. Перевод на русский.

Небольшое объявление

Привет всем кто меня читает 👋🏻

Как вы могли заметить за последние несколько месяцев не было ни одной статьи. В основном это связанно с тем что с нового года я работаю на новом проекте, а также активно готовлюсь к AWS сертификации.

В ближайшее время планирую сделать несколько заметок по AWS (EC2, Lamdba, API Gateway). Обновить или полностью переписать старые статьи по архитектуре.

Stay tuned 🚀

 Нет комментариев    39   1 мес  

Настройка новой виртуальной машины

Время от времени поднимаю виртуальные машины на убунту для своих проектов или экспериментов. Первое что я настраиваю — безопасность. Раньше у меня не было единого чек-листа и приходилось каждый раз гуглить. Поэтому решил сделать такой список и оставить у себя в блоге, чтобы обращаться к нему по мере необходимости.

Чеклист

  1. Создать нового пользователя вместо root.
  2. Настроить доступ по ssh ключам.
  3. Отключить доступ по паролю для ssh.
  4. Отключить доступ для root через ssh.
  5. Заблокировать все порты в ufw, кроме 80, 22 и 443.
  6. (необязательно) Поменять ssh порт с 22 любой другой

Terminal

# Создаем нового пользователя и добавляем в группу sudo.
adduser bstefaniuk
usermod -aG sudo bstefaniuk

# Копируем свой публичный ключ для нового пользователя.
ssh-copy-id [email protected]

# Отключаем доступ по паролю и root для ssh.
nano /etc/ssh/sshd_config
## Установить значения:
PasswordAuthentication no
PermitRootLogin no
## Перезапустить службу
systemctl restart ssh

# Настройка ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80
ufw allow 433
ufw enable
## Проверяем что все ОК
ufw status

В будущем хочу написать ansible-playbook скрипт, который будет все настраивать сам.

Хороший мануал по ufw
Генератор конфигураций nginx
Deployment: настраиваем пользователей

Google Cloud Associate Cloud Engineer

После полутора месяцев подготовки я получил сертификат Google Cloud — Associate Cloud Engineer.

Экзамен состоит из 50 вопросов и на их решение даётся два часа. Вопросы можно помечать и потом возвращаться к ним. Более того, разрешено возвращаться к любым вопросам в любой момент и что-то поменять. На ответы у меня ушёл 1 час + 20 минут на просмотр отмеченных вопросов.

Результат отображается сразу после отправки ответов. Всё что можно узнать это сдали вы или нет, нельзя посмотреть процент верных ответов или правильные ответы. Официальное письмо с сертификатов прийдут в течении 7-10 дней.

На этом я не закончу написания статей по GCP. Планирую рассказать про:

  • Network interconnect
  • Load Balancers
  • BigQuery
  • Мониторинг с помощью Stackdriver

GCP: Databases

Google Cloud Platform предоставляет большой выбор разных способов хранить данные. Некоторые из них построены на базе существующих продуктов, другие — собственная разработка гугла.

Для начала нужно понять, что такое managed databases. Это услуга по настройке и администрированию баз данных. Облачный провайдер сам отвечает за работу сервера, установку патчей безопасности, доступность сервиса. Для того чтобы достичь такого же результата с помощью self hosted, нужно иметь в штате специалиста, который умеет администрировать сервера, закупить железо и подготовить инфраструктуру. В случае с managed databases платишь только за то количество ресурсов, которое используешь.

Cloud SQL

Cloud SQL это классический managed database сервис. Он позволяет развернуть 3 самые популярные базы данных. Такие как:

  • MySQL (5.6, 5.7 и 8.0)
  • PostgreSQL (9.6, 10, 11, 12)
  • MS SQL Server 2017

Также гугл гарантирует доступность базы данных на уровне 99,95%. Дополнительно получаем автоматическую репликацию и бекапы.

Ограничения

  • 30 Tb хранилища
  • 60,000 IOPS
  • 624 Gb RAM
  • Реплики БД только для чтения

Cloud Spanner

Spanner — реляционная база данных, разработка Google. Spanner позиционирует себя как горизонтально масштабируемая база данных, способна хранить петабайты информации, гарантирует строгую согласованность данных. А также доступность 99.999%.

По своей природе Cloud Spanner это распределённая база данных с автоматическим шардированием и репликацией, которые скрыты под капотом. Чтобы создать БД, нужно выбрать локацию (region или multi-region) и количество нод. Количество нод влияет на размер данных, которые кластер способен хранить и его доступность. Каждая нода может обслуживать до 2 Тб данных.

Пример кластера, который состоит из 4 нод. Каждая зона содержит полную копию базы данных и 4 процесса, которые обслуживают эти данные.

Гугл советует иметь минимум 3 ноды для прода. Но есть один нюанс — цена. Cloud Spanner очень дорогое решение, созданное для работы с огромным количеством данных. За 1 петабайт данных прийдется отдать ......... 1 645 568 $ ......... в месяц.

Cloud Big Table

Столбцовая NoSQL база данных, которая масштабируется до миллиарда строк и тысяч колонок. Способна хранить петабайты информации.

Основная фича — наличие интерфейса HBase и нативная поддержка Hadoop. Это позволяет перенести данные с собственного кластера в Big Table без каких либо изменений. Big Table идеально подойдёт для очень быстрой записи и чтения, а также хранения данных типа ключ/значения, размер которых не превышает 10 Мб.

Данные внутри базы данных лежат в огромных таблицах. Грубо говоря, таблица в HBase представлена в виде огромного словаря словарей. Таблица состоит из строк, каждая из которых обычно описывает одну сущность, и столбцов, которые содержат отдельные значения для каждой строки. Каждая строка индексируется одним ключом, а столбцы, которые связаны друг с другом, обычно группируются в семейство столбцов.

Для более глубокого ознакомления советую прочитать главу «HBase» из книги «7 баз данных за 7 недель». Также советую ознакомится с официальной документацией.

Cloud Firestore

Cloud Firestore — это полностью управляемая,документоориентированная serverless база данных, предназначена для разработки serverless приложений. Структура данных сильно напоминает такую в MongoDB.

Firestore поддерживает офлайн режим и живую синхронизацию. С помощью этих фич удобно строить приложения, которые предназначены для совместного использования, например, Google Docs или другие похожие варианты.

А также она пришла на замену предыдущего сервиса — Cloud Datastore. В 2021 году гугл обещает автоматически всех мигрировать с Datastore на Firestore. Это возможно благодаря обратной совместировать с Datastore API.

Firestore имеет два режива работы:

  • Datastore mode, создан для серверных приложений, совместим с Cloud Datastore. Поддерживает согласованность в конечном счёте.
  • Native mode, создан для веб и мобильных платформ. Поддерживает строгую согласованость и все основные фичи Firestore.

Детальнее с режимами можно ознакомится в официальной документации.

Cloud Memorystore

Управляемый in-memory сервис, построенный на базе Redis и memcached.

Сравнение

GCP: Cloud Storage

Cloud Storage — сервис хранения неструктурированных данных. Внутри можно хранить все что захотим, но в основном используется как файловое хранилище. Каждый файл представлен в виде объекта, сами же объекты лежал в бакетах.

Бакет avatars содержит аватары пользователей, music — песни.

В Cloud Storage нету ограничений на количество и размер файлов. Мы платим только за то что используем.

Основные понятия

Бакеты
Бакет это коллекция объектов, все файлы должны лежать внутри. Также бакет является центральным местом управления жизненным циклом объектов и доступа к ним. Каждый бакет имеет свое глобально уникальное имя, регион и класс хранения данных. Для работы с бакетом используют конструкцию:

gs://название-бакета

Объекты
Технически Cloud Storage не является файловым хранилищем или файловой системой, это объектное хранилище. Поэтому каждый файл представляет из себя объект, который состоит из двух частей: сам файл и метаданные. Метаданные описывают характеристики объекта в виде ключ-значение.

Иммутабельность
Все объекты иммутабельные, их можно только перезаписать или удалить. При перезаписи предыдущая версия файла будет доступна пока новая успешно не запишется на диск.

Классы хранения

Классы хранения отвечают за доступность и цену хранения объектов.

Standard Storage
Лучший выбор для данных, которые активно используются (горячие данные) и хранятся непродолжительное время.

В свою очередь standard класс можно поделить еще на 3 подкласса: multi-regional, dual-region, single region. Они влияют на доступность файлов и скорость доступа к ним, особенно если пользователи разбросаны по миру. При использовании multi-regional класса автоматически выберется регион, который ближе к пользователю.

Nearline
Для этого и всех что ниже классов появляется стоимость за извлечение данных. Но хранение файлов дешевле.

Такое хранилище отлично подходит для данных, которые редко используются, обычно раз в месяц. Например, бэкапы или архивные данные. Если файлы нужны реже, чем один раз в квартал, лучше использовать Coldline или Archive классы.

Coldline
Используется для данных, которые нужны раз в квартал.

Archive
Самый дорогой в плане доступа к данным, но самый дешёвый для хранения. Файлы в нём должны храниться минимум 365 дней. Подходит для бэкапов и для аварийного восстановления. Но этот класс не имеет SLA для доступности.

gsutil

Для Cloud Storage есть своя консольная утилита. Большенство команд похожи на те что есть в Linux для работы с файловой системой.

С помощью gsutil можно:

  • Создать и удалить бакет
  • Загружать, скачивать, удалять объекты
  • Отображать список объектов
  • Перемещать, копировать и переименовывать объекты
  • Редактировать ACLs
  • Управлять версионированием

Пример команды, которая отобразит список объектов в бакете.

gsutil ls gs://some-bucket

Копирование файлов

gsutil cp -r <source> <target>

Безопасность

Cloud Storage поддерживает два механизма обеспечения безопасности: IAM и ACL.

IAM
Про IAM я рассказывал в предыдущей статье. По умолчанию есть 3 типа ролей, они распространяются на проект или бакет. Для тонкой настройки лучше использовать ACL.

  • Примитивные роли (owner/editor/viewer)
  • Standard Storage Roles — работают независимо от ACL
  • Legacy Roles — эквивалентны ACL разрешениям

ACLs
ACL приходят на помощь, когда нам нужно организовать атомарный доступ к отдельным объектам. Каждый элемент ACL состоит из разрешения и пользователя, кому эти разрешения выданы.

Что выбрать?
Первое что нужно понимать — IAM и ACL независимы и не влияют друг на друга. Если использовать оба механизма, можно выстрелить себе в колено. Убрав права на уровне IAM не забудь убрать из ACL.

Гугл советует использовать uniform подход, в котором используется только IAM. При таком подходе мы создаем бакет для конкретной группы пользователей.

Также у IAM есть система аудита, которая фиксирует все действия. Их можно проанализировать с помощью Big Query.

Signed URL
Иногда нужно дать доступ к файлу для пользователя, у которого нет гугл аккаунта. Тут на помощь приходит Signed URL. Он работает также как и ссылки в гугл документах. Единственное отличие в том что все ссылки имеют срок жизни, который мы указываем при создании.

С помощью этого механизма можем дать доступ на чтение, загрузку и удаление. Поэтому следите за тем кому даёте ссылку и с какими правами.

Шифрование

Google Storage всегда шифрует данные на сервере, перед тем как они будут записаны на диск. По умолчанию гугл использует собственные ключи шифрования. Но можно использовать собственные ключи или сгенерировать их с помощью Cloud Key Management Service.

Версионирование

Cloud Storage поддерживает версионирование объектов. Каждое изменение или удаление на самом деле не удаляет файл, а архивирует его. По умолчанию версионирование отключено, но его можно включить с помощью gsutil

$ gsutil versioning set on gs://bucket-name

Объекты для которых есть несколько версий имеют одно имя, но разные идентификаторы.

$ gsutil ls -a gs://my-files
gs://my-files/sample.txt#1602324272958747
gs://my-files/sample.txt#1602324615090803

Количество версий не ограничено из-за чего данные могут разрастись и сжигать больше денег. Для решения этой проблемы существует механизм управления жизненным циклом.

Также нужно помнить что архивные файлы имеют свои ACL, которые могут отличатся от актуальных!

Жизненный цикл

Жизненный цикл помогает поддерживать порядок в бакетах. С его помощью можно настроить количество версий, которые надо хранить, понижать класс хранения, удалять объекты после какой-то даты.

Общий вид правил:

В качестве условий можно использовать:

  • Возраст — время жизни в днях (TTL)
  • CreatedBefore — объекты созданные до даты (например до 1 апреля 2020)
  • IsLive — использовать актуальные или архивные файлы
  • MatchesStorageClass — текущий класс хранения
  • NumberOfNewerVersions — количество версий

Действия:

  • Удаление
  • SetStorageClass — поменять класс хранения

А вот так правила выглядят в жизни:

GCP: Identity and Access Management

Я уже кратко описывал работу прав внутри облака в статье “Google Cloud Platform”. Сегодня расскажу как устроен IAM.

Полики IAM содержат роль, пользователя или группу пользователей. Каждая роль содержит в себе список разрешений.

Модель доступа состоит из трех основных частей:

  • Участники (members). Любые учетные записи Google, сервисные аккаунты, Google Groups, Cloud Identity или GSuit домен.
  • Роль (role). Набор разрешений, определяют какие операции можно выполнять с указанным ресурсом.
  • Политика (policy). Объеденение роли и участников.

Также в качестве участника можно установить два специальных значения:

  • allUsers — любой пользователь в интернете
  • allAuthenticatedUsers — любой пользователь, авторизированный с помощью гугл аккаунта, даже если это личный аккаунт

Отдельно нужно упомянуть иерархию ресурсов. Она позволяет группировать ресурсы и централизованно управлять доступами используя систему наследования прав. Политики установленные на уровне папки будут распространятся на все проекты и подпапки.

Основные концепты

Ресурсы
Компоненты, которые выполняют работу. В основном права выдаются на уровне проекта. Но для некоторых ресурсов можно атомарно настроить права. Например выдать права администратора на конкретный экземпляр виртуальной машины.

Разрешения
Разрешения описывают операции, которые можно выполнять с ресурсами. Имеют следующий вид — service.resource.verb.

В большинстве случаев, разрешения соотносятся одним к одному с методами REST API. То есть, каждая служба Google Cloud содержит соответствующий набор разрешений для каждого метода REST API, который она предоставляет.

Роли
Роли — набор разрешений. Несколько разрешений желательно собирать в отдельную роль, которую назначать группе пользователей, вместо того чтобы раздавать разрешения напрямую пользователям.

Роли делятся на три типа:

  • Примитивная роль (Primitive) — самая простая и общая. Указывает какие действия можно выполнить со всеми ресурсами. Всего есть 4 примитивных роли: owner, editor, viewer и billing administrator.
  • Предустановленные роли (Predefined). Ими можно тонко настроить права. Указывают кто и какое действие разрешено выполнять с определенным ресурсов. Каждый ресурс в GCP содержит готовый набор predefined ролей.
  • Кастомные роли позволяют указать любой набор разрешений и предоставить их любому пользователю или группе.

Сервисные аккаунты

Сервисные аккаунты предназначены для взаимодействия ресурсов и сервисов друг с другом. Каждый аккаунт имеет уникальный email. Для того чтобы ресурс смог достучатся к другому, сначала нужно получить токен с помощью Google API и уже с ним идти в другой ресурс. Это происходит автоматически.

Отличия сервисных аккаунтов от обычных

  • Сервисный аккаунт не имеет пароля. Мы не сможем залогиниться через браузер.
  • Сервисный аккаунт содержит публичный и приватный ключ с помощью которого он авторизуется в облаке.
  • Разрешение serviceAccountUser позволяет выдавать пользователя за сервисный аккаунт.

Типы сервисных аккаунтов

  • Пользовательские, можно создать до 100 аккаунтов, количество можно увеличить, поменяв квоту. Такие аккаунты создаются со следующим электронным адресом: [email protected]
  • Дефолтные — для каждого проекта автоматически создаются два аккаунта, каждый имеет права Editor. Один используется для взаимодействия с App Engine ([email protected]), а второй для Compute Engine ([email protected]).
  • Аккаунты Google API — создаются и управляются на стороне Google, обеспечивают взаимодействие с сервисами гугла.

Рекомендации

  1. Следовать принципу наименьшей ответственности — выдавать пользователю только те права, которые ему необходимы.
  2. Выдавать права на группы, а не на отдельных пользователей.
  3. Внимательно следить за правами serviceAccountUser.

Больше советов можно посмотреть в документации: IAM recommender best practices.

GCP: виртуальные машины

Compute Engine

В основе почти всех ресурсов в Google Cloud лежат виртуальные машины, которые принадлежат сервису Compute Engine. Впервые они были представлены в 2012 году и отлично подойдут для любых запросов. По сути это обычные компьютеры с Linux или Windows на борту.

Создание виртуалок состоит из нескольких шагов:

  1. Выбрать регион и зону
  2. Определится с типом машины
  3. Выбрать образ
  4. Подключить дополнительные диски
  5. Настроить сеть

Типы VM

Перед созданием виртуальной машины нам нужно определиться с ее типом. Гугл уже насоздавал множество готовых конфигураций и объединил их в 6 групп:

  1. Standard
  2. High-memory
  3. High-CPU
  4. Memory-optimized
  5. Compute-optimized
  6. Shared-core

Если недостаточно представленных ресурсов, можно создать свою конфигурацию, выбрав нужное количество CPU или памяти. В зависимости от типа аппаратной платформы доступно до 96 vCPU, до 768 Гб памяти и диски до 257 терабайт. Каждая конфигурация основывается на соотношении CPU до памяти.

Кроме готовых конфигураций есть еще и аппаратная платформа, всего 4 варианта:

  • E2 машины имеют оптимизированный расход и содержат до 32 vCPU и максимум 8 Гб памяти на один vCPU. Также у них предопределена платформа процессора, работают на процессорах Intel, либо на AMD EPYC Rome второго поколения.
  • N2 расширяются до 80 vCPU и до 8 Гб памяти на один vCPU. Работают на процессорах Intel Cascade Lake.
  • N2D самые мощные в плане количества ядер машины, могут иметь до 224 vCPU, 8 Гб памяти на процессор и работают на базе AMD EPYC Rome.
  • Машины N1 предлагают до 96 процессоров, 6.5 ГБ памяти на один процессор, и доступны на платформах Intel Sandy Bridge, Ivy Bridge, Haswell, Broadwell и Skylake.

Детальнее в документации: https://cloud.google.com/compute/docs/machine-types

Образы

Образы операционных систем используются для создания загрузочных дисков машин. Мы можем выбрать готовый публичный образ, создать свой с загрузочного диска готовой виртуалки или загрузить с компьютера или другого облака.

Документация: https://cloud.google.com/compute/docs/images

Диски

После того как определились с типом виртуальной машины и образом, нужно выбрать диск. По умолчанию виртуальная машина идет с одним загрузочным диском. Образ загружается на диск при первом включении и дальше используется для работы виртуалки.

После удаления вуртуалки вместе с ней удаляется загрузочный диск. Для того чтобы выключить эту опцию нужно отключить опцию “Delete boot disk when instance is deleted”. Кроме того все диски автоматически шифруются ключами, которыми управляет гугл, но у можно использовать собственные ключи.

Для хранения данных есть постоянные диски. Они живут отдельной жизнью и подключаются к виртуальной машине по сети, что не так быстро как физически подключенные диски. Выбрать можем HDD или SSD. Первый дешевле, но медленнее чем SSD. Чтобы изменить размер диска не надо выключать виртуалку. В качестве бекапа выступают инкрементальные снапшоты.

Local SSD
Отдельный тип дисков, которые физически присоединены к виртуалке. Они производительнее чем постоянные диски и имеют меньшие задержки. Каждый диск расширяется до 375 Гб, что в сумме дает до 3 Тб на одну машину. Local ssd нельзя использовать для длительного хранения данных, так как стираются после выключения виртуальной машины, переживают только перезапуск.

Дока: https://cloud.google.com/compute/docs/disks

Жизненный цикл

Каждая виртуальная машины имеет свою жизненный цикл где каждая стадия отвечает за определенный набор действий. Всего есть пять состояний: Provisioning, Staging, Running, Stopping, Terminated.

Provisioning
Происходит после выбора всех необходимых настроек и нажатия на кнопку «создать VM». На этом этапе выделяется процессор, память и резервируются диски, но сама машина еще не работает.

Staging
На этом этапе происходит выделение внешнего и внутреннего IP адреса, загружается системный образ и стартует ОС.

Running
Сначала выполняются установленные start-up скрипты и включается удаленный доступ через SSH или RDP. Здесь выполняется вся возложенная на машину работа. На этом шаге можно мигрировать нашу виртуалку в другую зону без перезапуска, создавать снапшоты дисков или экспортировать системный образ.

Stopping и Terminated
Некоторые действия требуют остановки виртуальной машины, например добавление CPU или памяти. Когда машина переходит в это состояние выполняются установленные shutdown скрипты и VM переходит в terminated статус.

После этого мы можем ее удалить, мигрировать, добавлять и удалять IP адреса, теги, менять тип машины, добавлять новые диски.

Когда машина отключена мы платим только за выделенные IP и за диски. Главное что надо помнить, на выполнения shutdown скриптов есть всего 90 секунд, а если это preemptible машина, то 30 секунд.

Доступ к виртуальной машины

Linux манишь предоставляю доступ через SSH, а Windows — через RDP. В обоих случаях в брандмауэре должен быть открыт 22 порт для SSH и 3389 для RDP.

Специальные опции

Preemptible VMs
Временные и очень дешевые виртуальные машины. Обычно их используют для непродолжительной обработки больших массивов данных или расчетов. Например обработать больше количество картинок или подсчитать какие-то метрики. В свою очередь такие машины накладывают следующие ограничения:

  • Они могут быть выключены в любой момент, поэтому приложение должно быть fault-tolerant.
  • Google останавливает их после 24 часов работы.
  • Не всегда доступны для создания
  • Не предоставляют SLA

Sole-tolerant node
Если вы обрабатываете очень чувствительные данные, можно использовать sole-tolerant ноды, которые представляют физические сервера, которые изолированы от других проектов и клиентов.

Ранее Ctrl + ↓