'

Разработка и администрирование через тестирование - облачный сервис «Битрикс24» в Амазоне

Понравилась презентация – покажи это...





Слайд 0

Разработка и администрирование через тестирование - облачный сервис «Битрикс24» в Амазоне Александр Сербул 1С-Битрикс @AlexSerbul


Слайд 1

Наши цели Посмотреть на Amazon Web Services (AWS) с «птичьего полета» Научиться эффективно с ним работать, в т.ч. на PHP Уверенно развивать функционал, не отставая от рынка Держать созданную систему под постоянным контролем Изучить результат - сервис «Битрикс24» - изнутри


Слайд 2

AWS с «птичьего полета» Amazon Elastic Compute Cloud (EC2) – серверы и образы Amazon Elastic Block Store (EBS) - внешние диски Auto Scaling – масштабирование (от нагрузки и т.д.) Elastic Load Balancing - балансировщики Amazon Simple Storage Service (S3) – облачное хранилище Управляемый из кода хостинг с множеством реализованных Enterprise-паттернов :


Слайд 3

AWS с «птичьего полета» Amazon Simple Queue Service (SQS) - очереди сообщений Amazon Simple Notification Service (SNS) - уведомлялка Amazon Simple Email Service (SES) – рассылки почты AWS Identity and Access Management (IAM) – управление учетками


Слайд 4

AWS с «птичьего полета» Amazon CloudFront – CDN по всему миру Amazon Route 53 – управление DNS Amazon Relational Database Service (RDS) – MySQL с slaves и auto-failover Amazon DynamoDB, Amazon SimpleDB - NoSQL Amazon ElastiCache - «неубиваемый» memcached


Слайд 5

AWS с «птичьего полета» Amazon CloudWatch – мониторинг + аналитика Amazon Virtual Private Cloud (VPC) – собственная подсетка (с кластерами) Полезных сервисов много, готовые паттерны позволяют просто масштабироваться и обеспечивать неплохую отказоустойчивость (SLA до 99,95%).


Слайд 6

AWS с «птичьего полета» Availability zone (AZ) = «датацентр» Высокоскоростные каналы между ДЦ Region = группа связанных датацентров


Слайд 7

AWS с «птичьего полета» Availability zone (AZ) = «датацентр» Region = группа связанных датацентров Серверы (EC2) Диски (EBS) – доступны только внутри датацентра Снепшоты дисков Образы серверов Данные в облаке (S3) Учетки (IAM) Балансировщики и др. – реплицируются «между» датацентрами, на уровне региона


Слайд 8

AWS – все не так гладко Веб-сервисы внутри архитектурно отличаются друг от друга, в т.ч . по подходу и API. Не всегда удобно стыкуются. Прослеживается эволюция архитектур – например «наслоения концепций» в IAM/S3 Имеются неочевидные «жесткие» ограничения и лимиты – например число учеток в IAM (<=5000)


Слайд 9

AWS – нужно строить свое управляющее ядро Внутренняя система мониторинга CloudWatch - пока очень ограничена, уступает напр. Nagios/Munin Измерения внутри машин (top) и из CloudWatch – могут отличаться в разы (CPU, LA, др.) Нередко «соседи» на виртуальной машине внезапно влияют на производительность (CPU Stolen %) Нужно научиться держать конфигурацию под контролем, автоматизировав максимум операций.


Слайд 10

AWS SDK for PHP http://aws.amazon.com/php/ http://aws.amazon.com/sdkforphp/ REST API веб-сервисов Амазона Консольный клиент для unix, написан на java AWS SDK for PHP SSL (как правило) Библиотека, документация, примеры (2.1М)


Слайд 11

AWS SDK for PHP - документация http://docs.amazonwebservices.com/AWSSDKforPHP/latest/


Слайд 12

Бэкап данных в S3/Snapshots Unix: s3tools, s3fs AWS SDK for PHP: AmazonS3::create_object ( $bucket, $filename, $opt ) и др. AWS SDK for PHP: AmazonEC2::create_snapshot ( $volume_id, $opt ) AWS SDK for PHP: AmazonEC2::create_image ( $instance_id, $name, $opt )


Слайд 13

Бэкап данных в S3/Snapshots Нет инструментов очистки устаревших снепшотов и образов машин, их нужно писать (иначе можно упереться в лимит). Нужно писать оболочку, для повтора неудавшихся операций, логирования и т.п.


Слайд 14

Бэкап данных в S3/Snapshots … foreach ($vols as $path => $id) { $response = $ec2->create_snapshot($id, array('Description'=>"Snapshot:".$instanceRole.":".$path)); if ( $response->isOK() ) { bxc_log("Started snapshot for ($id): ".$response->body->snapshotId); $r = $ec2->create_tags($response->body->snapshotId, array( array('Key' => 'Name', 'Value' => "Snapshot:".$instanceRole.":".$path), array('Key' => 'Role', 'Value' => "Snapshot:".$instanceRole.":".$path), )); if ( !$r->isOK() ) { bxc_log_amazon_error($response, __FUNCTION__.":".__LINE__); } } else { bxc_log_amazon_error($response, __FUNCTION__.":".__LINE__); return false; } } Полезно создаваемым объектам присваивать тэги, для дальнейшей фильтрации


Слайд 15

Бэкап MySQL в S3/Snapshots Unix: ec2-consistent-snapshot или: “FLUSH TABLES WITH READ LOCK” 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 Хранилище данных (на базе S3 = Simple Storage Service) Снепшоты. Автоматически: консолидация бэкапов, сохранение только инкрементов


Слайд 16

Балансировка/Переключение трафика Хранилище данных (на базе S3 = Simple Storage Service) Снепшоты. Автоматически: консолидация бэкапов, сохранение только инкрементов Availability zone (AZ) = «датацентр» Region = группа связанных датацентров, SLA = 99,95% ДЦ1 ДЦ2 Балансировщик (ELB) Группа автомасштабирования (AutoScaling) CNAME к «myproj-1873425.us-east-1.elb.amazonaws.com», SSL-терминация


Слайд 17

Балансировка/Переключение трафика Хранилище данных (на базе S3 = Simple Storage Service) Снепшоты. Автоматически: консолидация бэкапов, сохранение только инкрементов Region = группа связанных датацентров ДЦ1 ДЦ2 Балансировщик (ELB) Группа автомасштабирования (AutoScaling)


Слайд 18

Балансировка/Переключение трафика Хранилище данных (на базе S3 = Simple Storage Service) Снепшоты. Автоматически: консолидация бэкапов, сохранение только инкрементов Region = группа связанных датацентров ДЦ1 ДЦ2 Балансировщик (ELB) Группа автомасштабирования (AutoScaling)


Слайд 19

Балансировка/Переключение трафика Хранилище данных (на базе S3 = Simple Storage Service) Снепшоты. Автоматически: консолидация бэкапов, сохранение только инкрементов Region = группа связанных датацентров ДЦ1 ДЦ2 Балансировщик (ELB) Группа автомасштабирования (AutoScaling) Мониторинг (CloudWatch) Образ машины (AMI)


Слайд 20

Балансировка/Переключение трафика Хранилище данных (на базе S3 = Simple Storage Service) Снепшоты. Автоматически: консолидация бэкапов, сохранение только инкрементов Можно гибко управлять тремя службами: ELB, AutoScaling, CloudWatch – подстраивая функционал под свои задачи Автоматическое увеличение числа машин при росте нагрузки Автоматическая замена вышедших из строя машин Переключение трафика в другой ДЦ при аварии сервиса или для проведения регламентных работ


Слайд 21

Балансировка/Переключение трафика AWS SDK for PHP: AmazonELB:: set_load_balancer_listener_ssl_certificate ( $load_balancer_name, $load_balancer_port, $ssl_certificate_id, $opt ) AmazonELB:: configure_health_check ( $load_balancer_name, $health_check, $opt ) AmazonELB::enable_availability_zones_for_load_balancer ( $load_balancer_name, $availability_zones, $opt ) AmazonELB::register_instances_with_load_balancer ( $load_balancer_name, $instances, $opt ) AmazonAS:: update_auto_scaling_group ( $auto_scaling_group_name, $opt ) AmazonAS: set_desired_capacity ( $auto_scaling_group_name, $desired_capacity, $opt ) и другие.


Слайд 22

Автоматическое масштабирование В CloudWatch создаем Alarm, который при среднем CPU>20% вызовет действие по добавлению в AutoScaling Group серверов, например, 2 машин (а также вышлет нам письмо) Создаем «обратный» Alarm, который при уменьшении нагрузки на CPU<10% будет убирать по 1 машине


Слайд 23

Система управления В CloudWatch недостаточно возможностей, но используем его максимально AWS SDK for PHP и вообще работа с API амазона не всегда прямолинейна – нужна прослойка Для основного мониторинга и активной обратной связи используем Nagios и его обработчики событий Для аналитики в основном используем Munin, часть данных берем из CloudWatch


Слайд 24

Система управления - тест Nagios AWS SDK for PHP Тест Тест Тест Тест Обработчик события Обработчик события Обработчик события CloudWatch - автомасштабирование Обработчик события Ядро Прослойка вспомогательного кода (PHP, bash) Утилиты AWS для консоли API Амазона Тест nagios Pinba Тест


Слайд 25

Система управления – обработчик события Nagios AWS SDK for PHP Тест Тест Тест Тест Обработчик события Обработчик события Обработчик события CloudWatch - автомасштабирование Обработчик события Ядро Обработчик события Прослойка вспомогательного кода (PHP, bash) Утилиты AWS для консоли API Амазона


Слайд 26

Что мы тестируем Стандартные тесты nagios: Пинг, LA, место на дисках Использование swap, число процессов Мониторинг raid (у нас 10 рейды из EBS-дисков) Безопасность – наличие обновлений софта Для общей картины - набор стандартных плагинов к Munin и несколько десятков графиков по каждой машине


Слайд 27

Что мы тестируем Базовые тесты MySQL: Состояние репликации – отсутствие ошибок, величина отставания slaves Buffer Pool hitrate Число активных потоков Число «долгих» потоков Частота создания на диске временных таблиц и другие


Слайд 28

Что мы тестируем Тесты времени выполнения страниц и использования памяти от pinba: Пиковое время выполнения страницы вирт. хоста Пиковое использование памяти вирт. хоста Среднее время выполнения страниц вирт. хоста с префиксом (по разделам) Среднее использование памяти вирт. хостом Среднее время выполнения агентов (после fastcgi_finish_request) Дополнительно выводим гистограмму распределения хитов по ступенькам времени (по pinba и по суточным логам)


Слайд 29

Что мы тестируем Тесты состояния амазона и превышения лимитов: Проверяем превышения ключевых лимитов амазона Число живых машин за балансировщиками Планируем проверять показатели нагрузки от CloudWatch – их, однако, очень мало Пинг на машину мониторинга nagios в другом регионе амазона и обратно (мониторинг мониторинга ?)


Слайд 30

Что мы тестируем Тесты выполнения бизнес-операций и обработчиков событий: Скрипты бэкапов и обработчики обновляют лог-файл (проверка времени модификации) Скрипты бэкапов и обработчики в обязательном порядке имеют лог ошибок (2> или error_log) – он должен быть пустым Лог ошибок очень помогает при работе с иногда «нестабильным» API амазона: Недоступность веб-сервиса Недоступность ресурса, хотя уже имеется его ID


Слайд 31

Администрирование через тестирование Перед добавлением любого сервиса или обработчика в обязательном порядке: Добавляется тест на проверку его «живости», иногда на число процессов с данным именем и т.п. Добавляется тест на наличие и своевременное обновление лог-файла обработчика/сервиса Добавляется тест на нулевой размер лога ошибок Сейчас в системе: около 1000 тестов, 5 сервисных групп, 4 групп хостов. Это конечно замедляет, однако позволяет уверенно двигаться вперед, менять конфигурацию, проводить эксперименты.


Слайд 32

Обработчики Обработчики стараются вернуть систему в рабочее состояние: При недоступности memcached(ов) делается временное переключение трафика в другой ДЦ При крахе машины MySQL или процесса, репликации – временное переключение трафика в другой ДЦ Проводится простая «реанимация» (рестарт memcached) и т.п. Если все сервисы поднялись – трафик возвращается обратно Обработчики для nagios написаны на bash, PHP/MySQL.


Слайд 33

Pacemaker/Heartbeat vs Nagios Было несколько безуспешных подходов понять стройность и красоту – Pacemaker/Heartbeat. Документация – ужасна. Пока нет доверия DRBD. Пишем свою простую автоматику на базе Nagios/PHP/MySQL и AWS ? Используем для кластера AutoScaling, шарды MySQL Master-Master (Active-Passive) и переключение трафика на балансировщиках (можно также Elastic IP). Картинка – ниже.


Слайд 34

Архитектура «Битрикс24» (www.bitrix24.ru) ДЦ1 ДЦ2 Балансировщики (ELB) Группа автомасштабирования (AutoScaling) Мониторинг (CloudWatch) Образ машины (AMI) SSL - терминация Percona XtraDB Master-Master (Active/Passive) Memcached Memcached Memcached Memcached Memcached Memcached Масштабирование PHP Масштабирование MySQL Файлы/Бэкапы/ Снепшоты – S3


Слайд 35

Спасибо за внимание Александр Сербул 1С-Битрикс serbul@1c-bitrix.ru @AlexSerbul Попробуйте http://www.bitrix24.ru 12 человек/5ГБ - бесплатно


×

HTML:





Ссылка: