2. Выбор платформы для
разворачивания инфраструктуры
Минусы размещения на собственном оборудовании:
Необходимы вложения в инфраструктуру на старте проекта
Сложность масштабирования
Сложность администрирования (в случае размещения в
территориально удаленных датацентрах)
Сложность резервирования на уровне ДЦ
Создание всех сопутствующих сервисов с нуля
«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить,
покупать собственные серверы или же выбрать одного из «облачных» хостинг-
провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести
собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой»
Брет Тейлор, технический директор Facebook
3. Почему Amazon Web Services?
Приложения тоже имеют «нормальные формы»
Многие этого не понимают
Риск изобретения неудачного велосипеда
Риск: «Зачем делать просто, если можно сложно?»
Используем опыт взрослых расширяемых архитектур
4. Почему Amazon Web Services?
Архитектор собирает костяк проекта «из «LEGO»
Основные усилия тратим на нестандартный функционал
6. Почему Amazon Web Services?
Можно легко мигрировать машины и сервисы между
датацентрами
Спасает при авариях
7. Amazon Elastic Compute Cloud EC2) и
вертикальное масштабирование
Практически моментальная доступность необходимого количества
виртуальных машин (instances) нужной конфигурации (от 613 Мб до
68 Гб RAM, от 1 до до 33.5 ECU CPU)
Множество готовых образов систем (различные дистрибутивы Linux,
Microsoft Windows Server, OpenSolaris)
Высокая доступность (99.95% - Amazon EC2 SLA)
Возможность использования дисков различной конфигурации
(Amazon Elastic Block Store (EBS))
Возможность размещения виртуальных машин в разных
датацентрах (регионах)
Безопасность: удобный файрвол для групп виртуальных машин
8. Запуск новой машины
Выбор образа (стандартные – Linux, Windows; собственные ранее
созданные; community)
Выбор типа машины
Выбор AZ
Public / private key
Security group
Другие опции (termination protection, набор дисков, shutdown
behavior и т.д.)
9. «Подводный камень» № 1
EC2 – практически тот же
VPS
Нет «волшебного
ползунка», чтобы гибко
задать конфигурацию –
как на старте, так и в
процессе работы
Нет моментального
вертикального
масштабирования
11. EC2 и IP
ec2-23-23-231-56.compute-1.amazonaws.com 10.10.26.123
23.23.231.56
Только 1 внешний IP у каждой машины
Разный резолвинг внутри и снаружи
Внутренний и внешний IP не постоянны (кроме
использования Elastic IP)
При организации рассылок – не забывайте про IN PTR
14. Облачные диски - EBS
Elastic Block Store: 1GB – 1TB
До 1000 IOPS/диск
AFR (annual failure rate) ~0.1-0.5% (при регулярных
снепшотах)
IO: десятки MB/sec – серьезно уступают «железным»
Хорошо помогает софтварный рейд (md)
raid0 или raid0+1?
Диски живут в одном «ДЦ», а их снепшоты между «ДЦ», на
уровне региона
15. Снэпшоты - EBS
Делать снепшоты рейдов можно и нужно
Нет инструментов очистки устаревших снепшотов и образов
машин, их нужно писать
Unix: ec2-consistent-snapshot
или:
fsfreeze –f mountpoint (Linux Ext3/4, ReiserFS, JFS, XFS)
AWS SDK for PHP:
AmazonEC2::create_snapshot ( $volume_id, $opt )
AmazonEC2::create_image ( $instance_id, $name, $opt )
fsfreeze –u mountpoint
16. AMI – образы машин
AMI – набор данных,
описывающих параметры
машины + загрузочный
образ
Делать снепшоты машин
целиком – гораздо
удобнее, чем по одному
диску
Машина переносится
между «датацентрами» -
целиком
17. Auto Scaling
Мониторинг (CloudWatch) Балансировщик (ELB)
ДЦ1 ДЦ2
Группа автомасштабирования (AutoScaling)
Region = группа связанных датацентров
Образ машины (AMI)
22. Elastic Load Balancing – особенности
Level 7 (HTTP) балансировщик «пропускает» не все методы:
например, не работают REPORT, SEARCH, MKCALENDAR
(WebDav, CalDav и т.п.)
Level 4 (TCP) не передает на бэкенд (EC2) real IP
При нагрузочном тестировании нельзя давать нагрузку
«ступенькой» - только постепенное плавное увеличение
23. Amazon Simple Storage Service (S3)
Если каждая веб-нода становится «расходным материалом»,
где хранить статический контент?
Разные типы хранилищ (наличие Reduced Redundancy
Storage – RRS)
SDK: Java, .NET, PHP, Ruby, iOS, Android
S3tools, s3fs, сторонние клиенты
Доступность – 99.99%
Надежность – 99.999999999%
ACL
Версионность
24. Интеграция приложения с S3
API хранилища для «прозрачной» работы с файлами
API для разработчиков (не используем стандартные
функции для работы с файлами)
Избегаем «диких» файлов
«Прозрачность» для всех модулей системы
Таблица с данными обо всех подключенных хранилищах
Таблица со списком файлов, и указанием, где они хранятся
(можно сразу хранить дополнительную информацию)
Не используем file_size, getimagesize и т.п. – сохраняем все
данные при аплоаде
26. Изоляция данных пользователей в S3
Раньше - новый IAM пользователь, получаем AccessKey,
SecretKey. Но есть лимит: макс. 15 000 (по умолчанию –
5 000)
Используем Security Token Service (STS) – временные
учетные записи
Права внутри одной директории:
PutObject
GetObject
DeleteObject
27. Деплой и обновления системного ПО
Как ставить
Сервер Новый обновления на
обновлений образ AMI нодах, не
допустив
рассинхрони-
зации данных
(веб и база)?
Web 1
Elastic
Load
Web 2 Balancing
Web N
28. Как работают обновления ПО
Как ставить обновления на нодах, не допустив
рассинхронизации данных (веб и база)
Каждое клиентское приложение работает с собственной базой.
Все обновления ставятся на выделенный instance, куда не приходит
нагрузка.
Из этого инстанса делается новый образ AMI.
Последовательно каждая машина помечается «плохой», при этом
новые веб-ноды стартуют уже из нового образа.
В веб-приложении существует механизм проверки соответствия версии
ПО и базы.
Если клиентский запрос приходит на ноду с новым ПО, а база еще
старая, по первому хиту происходит обновление.
29. База – RDS или не RDS?
У Amazon есть сервис RDS (Relational
Database Service). Можно использовать
MySQL или Oracle. Стоит ли использовать?
Недостаточно гибкая система (нет
полноценного root в базе)
Непрозрачно
Риск долгого даунтайма
Двойная стоимость машин при использовании
Multi-AZ
При этом – неэффективное использование
ресурсов
30. Конфигурация машин c базами MySQL
Виртуальная машина (EC2) - m2.2xlarge:
34.2 GB of memory
13 EC2 Compute Units (4 virtual cores with 3.25
EC2 Compute Units each)
64-bit platform
I/O Performance: High
EBS-Optimized Available: No
Диск может оказаться «узким» местом…
34. Software RAID – тесты sysbench
Режим random read/write. При увеличении количества потоков
единичный диск почти сразу достигает «потолка»,
производительность RAID растет.
35. MySQL? Percona Server!
Оптимизирован для работы с медленными дисками
Быстрый рестарт базы (Fast Shut-Down, Buffer Pool Pre-Load)
Множество счетчиков и расширенных отчетов
XtraDB Storage Engine
XtraBackup
BLOB, TEXT в таблицах MEMORY (HEAP)
37. Используем master-master
репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы
друг от друга: потеря связности между датацентрами может
составлять часы, данные синхронизируются после
восстановления.
Пользователь и все сотрудники этой компании работают в одном
датацентре за счет управления балансировщиком.
38. Вертикальное масштабирование базы
Для вертикального масштабирования используем slave,
потом переключаем его в master
Мониторим состояние master через
Веб-нода CloudWatch
Балансировка SQL Есть slave – минимальной конфигурации –
работающий в режиме только бэкапа
Elastic IP При необходимости масштабирования
меняем тип машины у slave (вертикальное
масштабирование)
Останавливаем master, делаем slave
MySQL мастером
MySQL slave Переключаем IP (Amazon Elastic IP) на
master машину с новым мастером
Веб-ноды не требуют
CloudWatch переконфигурирования и продолжают
работать без даунтайма
39. Горизонтальное масштабирование базы
Образ машины (AMI)
Миллионы таблиц,
десятки тысяч баз данных
Мониторинг Балансировщики (ELB)
(CloudWatch)
ДЦ1 ДЦ2
AutoScaling
Масштабирование PHP
DB1 DB1
(Active)
Вертикальный шардинг
(Passive)
Percona XtraDB Master-
Master (Active/Passive)
DB2 DB2
(Passive) (Active)
DB3 DB3
(Active) (Passive)
40. Бэкап MySQL
Unix: ec2-consistent-snapshot
или:
“FLUSH TABLES WITH READ
LOCK”
Буферы MySQL fsfreeze –f mountpoint (Linux
(InnoDB) в памяти Ext3/4, ReiserFS, JFS, XFS)
AWS SDK for PHP:
AmazonEC2::create_snapshot (
$volume_id, $opt )
AmazonEC2::create_image (
$instance_id, $name, $opt )
fsfreeze –u mountpoint
“UNLOCK TABLES”
Хранилище данных
Диск (EBS) (на базе S3 = Simple
Storage Service)
Снепшоты.
Данные MySQL Автоматически:
(InnoDB) на диске консолидация бэкапов,
сохранение только
инкрементов
41. Бэкап MySQL
Рецепта «100% целостного» снепшота файлов MySQL
похоже нет, нужно колдовать
Percona XtraBackup – инкрементальный бинарный бэкап
Нужно немало времени на подготовку бинарного бэкапа к
«чистому» быстрому восстановлению
Логический бэкап снимаем со слейвов
Случались тотальные разрушения raid10 при аварии в
амазоне – бинарный бэкап (или снепшот машины) +
бинлоги
42. Организация системы мониторинга
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не
самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё.
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Автоматизация типовых реакций.
Мониторить систему мониторинга.
В идеальном мире – распределенная система мониторинга.
«Мониторинг безопасности» – изменения файлов и т.п.
45. Автоматика – структура теста
Ядро
Nagios
Тест
Тест Тест
Тест Тест
Обработчик события Тест nagios
Обработчик события
Прослойка
Обработчик события вспомогательного кода Pinba
(PHP, bash)
AWS SDK for PHP
CloudWatch -
автомасштабирование
Утилиты AWS
для консоли
Обработчик события
API Амазона
46. Автоматика – обработчик
Ядро
Nagios
Обработчик события
Тест Тест
Тест Тест Прослойка вспомогательного кода (PHP, bash)
Обработчик события
Утилиты AWS
AWS SDK for PHP
Обработчик события для консоли
Обработчик события
API Амазона
CloudWatch -
автомасштабирование
Обработчик события
47. Автоматика
В CloudWatch недостаточно возможностей, но используем его
максимально
AWS SDK for PHP и вообще работа с API амазона не всегда
прямолинейна – нужна прослойка
Для основного мониторинга и активной обратной связи
используем Nagios и его обработчики событий
Для аналитики в основном используем Munin, часть данных
берем из CloudWatch
Присматриваемся к gearman, SQS
49. Аналитика – со стороны пользователя
Мало знать «среднюю температуру по больнице» и мониторить
только главную страницу сайта
Гистограммы распределения времени хитов, памяти, кодам
ответа и т.п. – из логов (awk-скрипт), pinba или других
инструментов
51. Пользовательская аналитика – в
графиках
Число ошибок в хитах за 15 минут - меньше L (из pinba)
Макс. время хита (тэга) – меньше M сек.
Макс. использование памяти хитом – меньше N МБ
53. Масштабируемость под высокие
нагрузки
Используем связку Elastic Load Balancing + CloudWatch +
Auto Scaling
Очень высокая посещаемость
Elastic Load Balancing
Web 1 Web 2
… Web N
CloudWatch + Auto Scaling
54. Отказоустойчивость узлов
Elastic
Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 в MySQL MySQL Датацентр 2 в
регионе US East master master регионе US East
master-master
(Virginia) репликация (Virginia)
Мониторинг и Мониторинг и
масштабирование – масштабирование –
CloudWatch + CloudWatch +
AutoScaling AutoScaling
management,
monitoring,
MySQL backup
55. Отказоустойчивость узлов
Elastic
Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 в MySQL MySQL Датацентр 2 в
регионе US East master master регионе US East
master-master
(Virginia) репликация (Virginia)
Мониторинг и Мониторинг и
масштабирование – масштабирование –
CloudWatch + CloudWatch +
AutoScaling AutoScaling
management,
monitoring,
MySQL backup
56. Отказоустойчивость ДЦ
Elastic
Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 в MySQL MySQL Датацентр 2 в
регионе US East master master регионе US East
master-master
(Virginia) репликация (Virginia)
Мониторинг и Мониторинг и
масштабирование – масштабирование –
CloudWatch + CloudWatch +
AutoScaling AutoScaling
management,
monitoring,
MySQL backup
57. Надежность «облака»
Само по себе «облако» не
надежнее традиционного
хостинга и собственного
оборудования. «Облако»
дает возможность
организовать надежную
инфраструктуру.
58. Спасибо за внимание!
Вопросы?
Александр Сербул Александр Демидов
serbul@1c-bitrix.ru demidov@1c-bitrix.ru
@AlexSerbul @demidov