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.

Сравнение

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 — поменять класс хранения

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

Я уже кратко описывал работу прав внутри облака в статье “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.

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 ноды, которые представляют физические сервера, которые изолированы от других проектов и клиентов.

Virtual Private Cloud (VPC) сеть — это виртуальная версия физической сети, которая работает внутри облака. С помощью сетей можно организовать общение между ресурсами в облаке или изолировать их друг от друга.

Общий вид проекта с одной сетью и двумя подсетями.

Составляющие компоненты VPC

• Регионы
• Зоны
• Проекты
• Сети
• Подсети
• IP адреса
• Маршрутизаторы
• Фаерволы

Региональные и зональные ресурсы

Я уже писал в предыдущей статье, что ресурсы в облаке разделяются по географии. К таким ресурсам относятся сети и их компоненты. Так к глобальным ресурсам относятся: VCP сети, firewall, маршрутизаторы. А к региональным статические внешние IP адреса и подсети.

Сети и подсети

Центральная единица в GCP — проект, объединяет набор ресурсов и сервисов в единую организационную единицу. Каждый проект содержат до 5 сетей, но это количество можно изменить, поменяв соответствующие квоты.

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

Сети разделяются на 3 типа: default, auto mode, custom.

Про диапазоны IP адресов можно почитать в Википедии.

Default сети
Они же auto mode сети, создаются автоматически при создании проекта. Каждая сеть содержит по одной подсети на каждый регион и имеет преднастроенный брандмауэр. Эти подсети по умолчанию содержат фиксированное количество адресов (/20) с возможностью расширения до /16.

Custom сети
Создаются вручную. По умолчанию не содержат подсетей, их нужно создавать самим, по мере необходимости. При этом у нас появляется полный контроль над IP адресами и диапазонами, главное чтобы они соответствовали RFC 1918 и не превышали размер /16. После создания подсети, количество адресов можно увеличить, но не уменьшить. Такие сети лучше всего подходят для продакшена.

Несколько VPC сетей могут взаимодействовать друг с другом с помощью внешних адресов или используя VPC Network Peering, который позволяет взаимодействовать с помощью приватных IP адресов, но работает только с custom сетями.

Двум виртуальным машинам нужно коммуницировать через внешний IP несмотря на то что они находятся в одном регионе.

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

IP адреса

Каждая виртуальная машина в GCP может иметь два IP адреса: внутренний и внешний.

Внутренние IP используются для коммуникации между ресурсами в одной сети. Их устанавливает DHCP и они являются эфемерными. Кроме IP адреса мы можем использовать имя вииртуальной машины, GCP автоматически прописывает его в DNS.

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

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

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

Firewall

Каждая сеть имеет фаервол, в нём можно настроить правила для входящего(ingress) и исходящего(egress) трафика. По умолчанию весь ingress трафик запрещён, а egress разрешён. Поэтому для входящего трафика мы можем создать только разрешающие правила.

Сами правила можно применять для конкретного IP адреса, множества или для тегов. Например, создать правило, которое разрешает HTTP трафик для экземпляров с тегом «allow-http».

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