[Перевод] Сравнение производительности железного сервера и облака Amazon
Уверен, эти вопросы некоторым знакомы, потому что меня много об этом спрашивали:
- Должен ли я использовать AWS или обычный железный сервер?
- Какой тип сервера выбрать на Amazon?
- Использовать для базы данных Amazon RDS или EC2?
- Выбрать у Amazon выделенные или инстансы по требованию?
- Сколько транзакций может обрабатывать сервер каждого типа?
Цель статьи — решить эти вопросы. Конечно, на них нет прямого ответа, он будет начинаться со слов «зависит от …». Но я надеюсь, мой анализ все же поможет вам принять правильное решение.
Среда тестирования
В левом углу ринга удивительный выделенный железный сервер HP DL380 G9 со следующими спецификациями:
CPU: 16 cores (Dual Socket Octo Core Intel Xeon E5–2630v3 2.4GHz, #Processors: 2, #Cores per Proc: 8)
RAM: 128 GB
DISKS: 500 GB RAID 5 SSD
А в правом углу ринга два сервиса Amazon: EC2 и RDS. Чтобы добиться таких же характеристик, как на железном сервере, я использую два инстанса базы данных: DB1 (Memory Optimized) и DB2 (Compute optimized). Спецификации следующие:
DB1:
r3.4xlarge (memory optimized)
16 cores
122 GB RAM
320 GB SSD Instance Storage
DB2:
c3.8xlarge
32 cores
60 GB RAM
750 GB io1 EBS 7500 IOPS
Я также протестирую инстансы с разными типами аренды: выделенные и по запросу, плюс EBS-оптимизацию для инстанса, в который она не включена по умолчанию (например, r3.4xlarge).
Обратите внимание:
- Я не тюнинговал RDS или EC2 сервисы, использовал только стандартные конфигурации
- Результаты могут варьироваться в зависимости от зон доступности (AWS) и регионов
- В отличие от железных серверов, в Amazon есть некоторые накладные расходы на HVM-виртуализацию
Условия тестирования
- Операционная система для EC2 и железного сервера: Ubuntu 14.04 LTS x64
- Типы инстансов EC2: r3.4xlarge и c3.8xlarge
- Типы инстансов RDS: db.r3.4xlarge и db.m4.10xlarge (инстанс db.c3.8xlarge недоступен на RDS, поэтому я заменил его инстансом уровнем выше)
- Объёмы: 320 ГБ SSD для DB1 и 750 GB IO1 7500 IOPS для DB2
- Движок MariaDB: 10.0.17
- SysBench версия: 0.4.2
- SysBench test: OLTP complex test
- Команда для запуска SysBench:
sysbench --db-driver=mysql --num-threads=$THREADS --max-requests=0 --test=oltp --mysql-table-engine=innodb --oltp-table-size=2000000 --max-time=60 --mysql-engine-trx=yes --mysql-user=$USER --mysql-password=$PASSWORD --mysql-host=$HOST run
- Максимальное количество подключений (конфигурационный файл my.cnf): 300
- Потоки: от 1 до 256
- Хост для запуска sysbench: localhost для EC2, для RDS — в той же зоне доступности
- Результаты: количество транзакций в секунду по итогам SysBench-теста
- SysBench-тесты проводятся изолированно от других тестов
«Лучшие практики» AWS
Прежде чем перейти к тестированию, хочу показать вам рекомендации Amazon. В 2015 году компания выпустила подробный Whitepaper по запуску реляционных баз данных на EC2 и RDS. Полную документацию вы найдёте по ссылке.
Вот краткая выдержка из документа:
Рекомендуем сначала рассмотреть Amazon RDS. Это лучший выбор, если:
- Вы сосредоточены на задачах высокого уровня, таких как настройка производительности, оптимизация схемы. Вы ждёте, что Amazon предоставит базу данных, будет управлять резервным копированием и восстановлением данных, патчами безопасности, обновлять версии SQL Server (СУРБД) и управлять хранилищем.
- Вы ищете высокодоступное решение для базы данных и хотите использовать синхронную репликацию Multi-AZ по нажатию одной кнопки без нужды вручную настраивать и поддерживать зеркалирование базы данных, отказоустойчивую кластеризацию или группы доступности AlwaysOn.
- Вы не хотите управлять резервным копированием и, главное, восстановлением базы данных к определённой точке во времени — предпочитаете, чтобы AWS автоматизировал этот процесс.
Лучше запустить SQL Server на EC2, если:
- Вам нужен полный контроль над инстансами базы данных, включая доступ к операционной системе и программному стеку.
- Вы хотите, чтобы ваши собственные администраторы управляли базой данных, включая резервное копирование, репликацию и кластеризацию.
- Размер и производительность базы данных превышают текущие максимумы или другие ограничения RDS Amazon.
- Вы хотите использовать возможности или опции SQL Server, которые не поддерживает Amazon RDS.
- Вы хотите настроить решение для аварийного восстановления при работе с SQL Server на AWS, как источника.
- Необходимо использовать версию SQL Server, неподдерживаемую Amazon RDS (например, версию 2014-ого года, которая не поддерживается на момент написания статьи).
Результаты
Как я уже говорил, у нас есть два бойца на ринге, так что в результате мы получим железный сервер против AWS. Поскольку мы используем пару сервисов Amazon, будет несколько тестов:
- EC2 и RDS на базе DB1 по сравнению с железным сервером
- EC2 и RDS на базе DB2 по сравнению с железным сервером
Результаты очень интересные, попробуем проанализировать:
- Значения для обоих EC2 серверов очень похожи, растут линейно до 16 потоков, а потом останавливаются и остаются почти на том же уровне даже после увеличения количества потоков.
EBS-оптимизация немного увеличивает количество транзакций в секунду для большего количества потоков. - Выделенные инстансы практически не влияют на производительность. Результаты для выделенных и инстансов по требованию очень похожи — разница буквально 2–3%. А значит выделенные инстансы не ускоряют работу БД, но обеспечивают безопасность данных. Так как изолированы от инстансов других пользователей на уровне аппаратного обеспечения хоста.
- Инстансы «Compute optimized» показывают производительность немного ниже, чем инстансы «Memory Optimized» на обоих тестах: для EC2 и RDS.
- RDS с меньшим количеством потоков ведёт себя несколько хуже, чем EC2 или железный сервер, этот разрыв сохраняется до 16 потоков. Начиная с 16 потоков производительность RDS стремительно растёт с большим отрывом от EC2. На 256 потоках значение для RDS втрое больше.
- Железный сервер показывает хорошие результаты для меньшего количества потоков и проигрывает RDS, начиная со 128 потоков.
- Железный сервер показывает свой лучший результат на 32 потоках, при более высоких показателях значение уменьшается.
Вывод
Как вы видите из графиков выше, инстансы EC2 недостаточно хорошо работают для высоконагруженных систем с огромным количеством соединений. Поэтому на вопрос «Использовать для базы данных Amazon RDS или EC2?» я должен ответить: «Зависит от …». Если вы работаете с высоконагруженной базой данных с огромным количеством соединений, то определённо должны выбрать RDS. По сравнению с железными серверами он показывает неплохие результаты, несмотря на разницу при меньшем количестве потоков. Но если вы используете кластерную систему с парой подчинённых узлов и количеством потоков меньше 16, выберите EC2 — этот сервис немного лучше работает при меньшем количестве потоков.
На вопрос: «Должен ли я использовать AWS или железный сервер для моей базы данных» отвечу также: «Зависит от …», только помните что:
Железный сервер Физический выделенный сервер |
Облако IaaS Виртуальные машины в публичном облаке |
|
---|---|---|
П л ю с ы |
|
|
М и н у с ы |
|
|
По заявлению Amazon выделенные инстансы главным образом обеспечивают безопасность данных. Результаты тестирования по разным регионам плавающие — отличаются буквально на 2–3%. В основном это зависит от нагрузки на регион и, как следствие, расхождения графиков. Я бы не стал рассматривать выделенные инстансы как способ увеличить быстродействие БД.
И да, до сих пор сложно ответить на вопрос: «Сервер какого типа я должен выбрать на Amazon?». Но я советую запускать базу данных для высоконагруженных систем на RDS. Если все же решите использовать EC2, то инстансы Memory Optimized с EBS-оптимизацией — лучший выбор.
Комментарии (5)
25 апреля 2017 в 14:38 (комментарий был изменён)
+1↑
↓
Железный сервер минусы: дороже
Как раз таки все (в том числе и мы), переезжают с RDS на выделенный сервер из за дороговизны RDS (поищите эту тему в гугле). Экономия такая — 3000$/мес RDS, 550$/мес выделенные сервера. Единственное что, пришлось потратить время на разворачивание кластера, настройки бекапов, но это одноразовое вложение.
25 апреля 2017 в 22:04
0↑
↓
одноразовое вложение
А поддерживать этот кластер? Проверять бекапы, производить восстановление?
Если для этого изначально есть админы (которому нужно платить деньги за все это), то зачем нужно было использовать RDS?25 апреля 2017 в 23:36 (комментарий был изменён)
+1↑
↓
вы осознаете ценовую разницу? 3000$/мес vs 550$/месза эту разницу можно нанять фултайм человека на один сервер… что никто конечно делать не будет, обычно это либо аутсорс, либо у вас уже есть админ, который решает другие задачи, просто будет еще одна.
25 апреля 2017 в 21:29
0↑
↓
Наверное, для БД имело смысл протестировать High I/O Instances EC225 апреля 2017 в 23:01
+2↑
↓
Облако хорошо для старта компании.
Когда у компании появится «жирок» тогда можно задумываться о своем физическом сервере (ах).Хороший пример Weta Digital, которая зарождалась в еще далеких 90-х годах и создавшая самые крутые спецэффекты для более чем 50 голливудских блокбастеров, сейчас владеет СВОЕЙ самой огромной рендер-фермой, которая тоже была задействована для создания Аватара. Для рендеринга сцен фильма Weta использовала серверную ферму площадью 930 м2 с использованием 4 тыс. серверов компании Hewlett-Packard, имевших в общей сложности 35 000 процессорных ядер под управлением операционной системы Ubuntu.
А ведь в те времена миллионеры!!! взяли напрокат компьютер и установили его в задней части обветшалого дома в Веллингтоне, что в Новой Зеландии.