Upload
tfmailru
View
6.437
Download
2
Embed Size (px)
Citation preview
ФО́� РУМ, (лат. forum) - Площадь в древнем Риме, на которой сосредоточивалась общественная жизнь города (ист.).
|| перен. употр. для обозначения того, что является центром, средоточием чего-нибудь.
Как задать вопрос докладчику?
• Через веб-форму http://techforum.mail.ru/question
• SMS на номер 2420, начиная сообщения с ZAL1 или ZAL2 (стоимость SMS сообщения 1.7 рубля)
• Twitter: #ZAL1 и #ZAL2
Стабильность – признак мастерства.
Важна ли стабильность для интернет-проекта?
Большинство сервисов в интернете бесплатно.
Порог вхождения в конкурирующие сервисы очень низкий.
О́трицательные эмоции полученные от недоступности сайта помнятся дольше и ощущаются сильнее, чем положительные.
Средний uptime интернет-сервиса: 98.60%.
Что такое 98.60% ?
7356 минут простоя в год.
123 часа простоя в год. 5 суток простоя в год.
Средний uptime крупных сайтов рунета: 99.96%.
(примерно 4 часа простоя в год).
Немного статистики:
Немного статистики:
8%1%
25%
50%
16%
Количественное распределение :
Сетевые аварии
Аварии датацентров
Программные аварии
Аварии при деплое
Аварии оборудования
30%
30%
15%
20%
5%
Качественное распределение:
10 причин иметь мониторинг
Вы не должны узнавать о вашей проблеме от ваших пользователей.
О́бсуждение downtime-а приносит больший урон репутации, чем сам downtime.
По закону Мерфи ваш сайт обязательно упадет. Чем раньше вы узнаете о проблеме – тем быстрее она будет решена.
Большинство ISP не будет нести ответственность за downtime вашего сайта.
10 причин иметь мониторинг
Хороший мониторинг расскажет не только то, что ваш сайт лежит, но и почему именно.
Стоимость создания мониторинга ничтожна по сравнению со стоимостью разработки сервиса.
Без мониторинга невозможно отследить системные проблемы в разработке. С вашим вебсайтом может быть все ок, но в остальном интернете его никто не увидит.
Вы должны знать о проблеме даже ночью (в России 9 часовых поясов).
Какие мониторинги бывают в Mail.ru?
Мониторинг сетевой доступности.
Мониторинг скорости работы сайта.
Мониторинг работы сервиса (ответ по HTTP). Функциональный мониторинг сервисов.
Мониторинг заполняемости хранилищ данных.
В Mail.ru более 140 различных типов мониторингов и более 150 тысяч объектов наблюдения.
Мониторинг статистических выбросов. Мониторинг мониторинга.
Как добиться аптайма в 100% ?
Резервирование и балансировка
Различные уровни резервирования:
Автоматический ввод резерва.
Тип сервера Необходимое резервирование
Сервера обработки данных N+1
Хранилища данных 2N + offline копия
Сеть 35%
Quagga
Keepalived
Router
IPVS
Что нужно что бы сделать отказоустойчивую систему:
Простейший роутер с поддежкой RIP
Средство общения с роутером по RIP.
Балансировщик и энкапсулятор траффика в IPencap.
Утилита проверки живости серверов.
Internet
Датацентр 1
Quagga
Группа серверов
Router
IPVS
Keepalived
RIP: updateRIP: poison reverse
IPencap
траффикПроверка
работы фермыПрямой,
неинкапсулированный
ответ сервера
Об
новлени
е табл
иц
ы
IPV
SОтвет
пользователю
В другой
датацентр Запрос
Internet
Датацентр 1 Датацентр 2
QuaggaIPVSKeepalived
Группа серверов Группа серверов
QuaggaIPVSKeepalived
QuaggaIPVSKeepalived
Router Router
QuaggaIPVSKeepalived
Балансировщик Балансировщик Балансировщик Балансировщик
Для того что бы все это на самом деле заработало:
1. Патчим таймеры RIP-update в Кваге уменьшая их до 1 сек.2. Патчим Квагу еще раз так, что бы административно выставленная RIP-метрика не попадала в poison reverse пакет.
4. Выключаем IRQbalance, балансировать будем вручную.
3. Патчим KeepAlived таким образом что бы пакет уходящий на real server был 1500 байт.
Модульная архитектура проекта.
Кешируйте «негативные» ответы.
Разделяйте нагрузку по типам.
Деградируйте сервис вместо того, что бы «упасть» целиком.
Работайте с модулями асинхронно.
Релиз-менеджмент и тестирование
Чем более автоматизирован процесс релиза – тем меньше сюрпризов.
Половина проблем стабильности связанно с релизом нового кода. Релиз менеджменту - быть.
Сплит-тестирование.
Каждый раз релизим «все», а не только готовое.
Прогнозирование нагрузки
Помните о специфике вашего проекта.
Имейте оценку нагрузки релиза, пусть даже неточную.
Следите за графиками.
Часто разрабатывают популярные фичи одни люди, а прогнозируют нагрузку другие.
Имейте пороговое значение времени ответа.
Планирование аварий
Время потраченное на придумывание воркэраунда можно сэкономить, если спланировать аварию заранее.
Автоматизированная выкатка бекапа.
Заглушки и «лайт-версии».
Верить нельзя никому!
По результатам каждого сбоя должно быть проведено обсуждение что прошло хорошо, а что не очень.
Проверьте сами, что все заработало.
Любые планы восстановления после сбоя должны регулярно проверяться. Бекапы.
Вопросы?
Владимир Габриелян[email protected]
СПАСИБО́!