Подробности об Amazon Elastic Block Store
Теперь, когда сервис Amazon Elastic Block Store доступен широким массам, настало время глубже изучить его возможности. Официальная информация о EBS находится на сайте AWS-сервисов и мы рассмотрим только наиболее важные моменты его функционирования.
Основы
Начать работу с EBS очень просто: вы создаете том размером от 1GB до 1TB, затем подключаете как блочное устройство (типа /dev/sdj) к виртуальной машине, форматируете и используете. В дальнейшем его можно отключить и через какое-то время подключить к другой виртуальной машине. Вы также имеете возможность сделать в любое время снэпшот тома в хранилище S3 и, при необходимости, из этого же снэпшота создать новый том. Звучит просто, но, как обычно, существует куча деталей.
Надежность
Тома EBS имеют встроенную поддержку отказоустойчивости, которая обеспечивает доступность данных при выходе из строя любого элемента. Но, к сожалению, эта отказоустойчивость не дотягивает до отказоустойчивости S3, который производит репликацию своих данных в разные датацентры. На практике это означает, что важно уделять внимание созданию резервных копий томов, организованных снэпшотами в S3.
Ребята из Amazon потратили кучу времени на составление документации, поэтому было бы неправильным не привести здесь часть этого документа:
Тома Amazon EBS спроектированы таким образом, чтобы одновременно иметь высокую доступность и надежность. Данные каждого тома EBS реплицируются между несколькими серверами в одной зоне доступности (датацентре), что позволяет предотвратить их утерю из-за одиночного отказа любого компонента. Долговечность самого тома зависит от его размеров и процента измененных данных с момента последнего снэпшота. К примеру, если том содержит 20Gb или меньше измененных данных после того, как последний раз был выполнен снэпшот, показатель годовой уровень отказа (annual failure rate – AFR) будет около 0.1% – 0.5%, при котором все данные могут быть утеряны. Это сравнимо с традиционными жесткими дисками, чей показатель AFR около 4%, таким образом делая тома EBS в 10 раз надежнее, чем обычные диски.
С практической точки зрения это означает, что вы должны полагаться на такой же уровень надежности как у дисковых RAID-систем. При необходимости, следует рассмотреть возможность увеличения надежности, к примеру, создав из двух томов EBS зеркальный раздел. Сфокусируйте свои усилия на построении хорошей стратегии регулярного выполнения снэпшотов и проведении мероприятий по опытному восстановлению данных при моделировании различных отказов.
Производительность тома
Наши исследования производительности базируются на предварительном релизе сервиса EBS, и выполнены под наименьшей возможной нагрузкой сервиса, поэтому не могут гарантировать того, что эти показатели будут достигнуты на реальной системе. Это может показать только время.
Тома EBS являются сетевой системой хранения данных и их производительность зависит от общей пропускной способности всей сети. Так как мы имеем скорость сети на уровне 1 гигабит в секунду, то пиковая скорость передачи данных будет около 120 мегабайт в секунду. В наших тестах программа sysbench на виртуальной машине типа m1.small показала производительность 70Mb/секунду, что является неплохим результатом. В момент проведения тестов, мы предположительно не конфликтовали с другими виртуальными машинам, запущенными на том же физическом сервере.
На тесте случайного обращения были получены результаты около 1000 операций ввода/вывода в секунду.
Используя EBS возможно увеличить производительность транзакций путем подключения нескольких томов к одной виртуальной машине и блочного размещения на них одной файловой системы. Несмотря на то, что в этом случае производительность всей системы скорее всего упрётся в пропускную способность сети, разнесение по томам должно дать прирост за счет уменьшения операций, приходящихся на один физический привод.
Снэпшоты
Снэпшоты являются наиболее полезной в эксплуатации и наболее трудной в понимании возможностью EBS. Я все же попробую объяснить доступными словами. Снэпшот тома EBS может быть выполнен в любое время и приводит к созданию копии всех данных тома, которые помещаются в S3 и хранятся с дублированием в нескольких зонах доступности. Первой особенностью отличающей их от обычных разделов S3, является то, что эти данные невидимы для доступа с помощью традиционного API S3. Со снэпшотами можно работать только используя API EC2, получая их список и производя восстановление данных в новый том. Второй особенностью является то, что все снэпшоты инкрементальны, а это означает, что EBS производит только запись тех блоков файловой системы, которые изменились с момента создания последнего снэпшота.
Принципиальная схема работы инкрементальных снэпшотов приведена на рисунке ниже. Каждый том делится на блоки. При создании первого снэпшота в хранилище S3 копируются все блоки файловой системы, которые содержат какую-либо информацию, после чего осуществляется составление таблицы этих блоков. При создании второго снэпшота того же самого тома, производится сохранение только блоков, которые изменились с момента прошлого снэпшота. Таблица содержимого второго снимка будет также содержать список его блоков. Однако некоторые из них будут новыми (те, которые изменились с момента прошлого), другие же ссылаться на данные первого (те, которые не изменялись). Третий снэпшот создается подобным образом, но может уже включать блоки и из первого, и из второго и из третьего снэпшотов.
Это алгоритм порождает два значительных преимущества инкрементальных снэпшотов перед цельным копированием данных: они создаются быстрее и занимают меньше пространства. К сожалению, очень сложно спрогнозировать, сколько всего будут занимать места несколько снэпшотов, или, к примеру, сколько пространства освободится при удалении одного из них. Если вы удаляете один из снэпшотов, то реально происходит удаление только блоков, используемых только этим снэпшотом.
В некоторых случаях необходимо с большой осторожностью относиться к целостности снэпшотов. Несмотря на то, что на передачу данных в S3 требуется какое-то время, снэпшот всегда создается как снимок по состоянию на определенный момент времени. Особенно следует внимательно планировать их работу на серверах баз данных. Мы рекомендуем замораживать базу данных, сбрасывать весь кэш файловой системы, производить снэпшот и затем размораживать базу. В качестве файловой системы мы используем XFS, так как она поддерживает быстрое форматирование и замораживание, и при создании снэпшота мы делаем заморозку XFS, формируем образ и затем размораживаем файловую систему. При работе с MySQL также рекомендуется выполнять операцию «flush all tables». Это позволяет убедиться, что снэпшот не будут иметь каких-либо данных в кэше, которые при повторном монтировании могут повредить файловую систему.
Скорость выполнения снэпшотов близка к производительности самой S3 и составляет приблизительно 20 мегабайт в секунду для одного потока. К этому добавляются три огромных плюса: инкрементальная природа снэпшотов, сжатие передаваемых данных и то, что все это происходит в фоновом режиме без необходимости отключения тома. Очевидно, что передача данных занимает какое-то время, однако оно не сопоставимо с побайтовым копированием данных с диска на S3.
Датацентры
Тома EBS могут быть подключены к виртуальной машине только из той же самой зоны доступности (или проще говоря датацентра). Хотя технически нет никаких проблем подключать тома, находящиеся в других датацентрах, сетевые задержки и ограничение пропускной способности катастрофически повлияют на работоспособность системы.
Существует способ как можно произвести перенос данных тома из одного датацентра в другой через снэпшот: вы можете сделать снэпшот одного тома и затем сразу же создать новый том с использованием этих данных. Это является самым оптимальным вариантом и следует выбросить все мысли из головы о возможности отключения тома от одного сервера и подключения его же к другому в другом датацентре: всегда такие действия необходимо проводить через снэпшоты.
Алгоритм следующий:
- Вы создаете том, подключаете его к виртуальной машине, форматируете и записываете на него какие-то данные.
- Затем периодически делаете снэпшоты для резервного копирования.
- Если более не требуется работа виртуального сервера, вы можете завершить его работу и после отключения тома выполнить окончательный снэпшот. Если не дай бог, происходит сбой в работе виртуального сервера, у вас всегда сохранится этот последний снэпшот.
- Затем вы запускаете новый сервер, которому необходимы те же данные, и создаете новый том из снэпшота на выбор. Это может быть последний, или предпоследний (в том случае, если произошел отказ программного обеспечения и данные были утеряны).
В некоторых случаях есть смысл напрямую выполнять переключение томов от одной виртуальной машины к другой без создания промежуточного снэпшота. Это допустимо, если вторая виртуальная машина находится в том же датацентре.
Цены
Оценить общие расходы по сервису EBS довольно сложно. Самой простой статьей затрат будет стоимость $0.10 за GB в месяц. После того, как вы создадите том заданного объема, включится биллинговый механизм. Вторая составляющая стоимости в $0.10 за миллион транзакций порождает затруднения в понимании объемов начислений. Чтобы получить приблизительную оценку можно взглянуть на содержимое файла /proc/diskstats на сервере. Вы увидите подобную информацию:
8 160 sdk 9847 77 311900 56570 1912664 3312437 160672914 211993229 0 1597261 212049797 8 176 sdl 333 86 4561 1538 895 51 19002 20131 0 4043 21669
которая по началу покажется обычной мешаниной цифр. Вам необходимо просуммировать первое число после названия блочного устройства (количество чтений) и пятое (количество записей) для получения оценочного числа транзакций ввода/вывода (9847+1912664 для /dev/sdk в нашем примере). Этот показатель не будет точным на 100%, но хотя бы даст общее представление. Следует отметить, что наш основной сервер баз данных, который выполняет в среднем 17 транзакций в секунду, обходится по этой статье затрат в $4.40 в месяц. Но тем не менее сервера мониторинга до проведенной недавно оптимизации выполняли более 1000 случайных операций записи в секунду круглые сутки. В итого это обошлось в $250 в месяц. Поэтому в большинстве ситуаций стоимость транзакции в EBS будет незаметна, но также и может быть существенной, если не заботиться о производительности.
Стоимость снэпшотов оценить еще сложнее из-за их инкрементальности. Для начала в S3 будут помещены только блоки файловой системы, которые уже содержат какие-либо данные (и соответственно пустые блоки в S3 не сохраняются). Второй проблемой является то, что стоимость последующих снэпшотов будет зависеть от количества измененных данных до предыдущего.