от авгиевых конюшен к звездам
•Descargar como PPTX, PDF•
0 recomendaciones•1,490 vistas
путь проекта из концепта в продакшин глазами системного администратора
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a от авгиевых конюшен к звездам
Similar a от авгиевых конюшен к звездам (20)
от авгиевых конюшен к звездам
- 1. 9-я конференция .NET разработчиков 12 октября 2014 dotnetconf.ru От авгиевых конюшен к звездам Гончаров Лев ByndyuSoft ultralisc@gmail.com
- 3. 3 Задача Максимальная отказоустойчивость при минимальном бюджете
- 4. 4 Crawlers
- 5. 5 Crawlers • Скачать • Обработать • Сохранить
- 6. 6 Crawlers
- 7. 7 Crawlers. Их много, ты один • Упростить развертывание • Ввести метрики эффективности работы • Сбор ошибок • Необработанные исключения тоже надо собирать
- 8. 8 MsSQL
- 9. 9 MsSQL Описание: • Хранит данные за пол года • БД до 1ТБ
- 10. 10 MsSQL Cluster • Общее хранилище • Transactions logs • Log shipping • AlwaysOn • Mirroring
- 11. 11 MsSQL медленно работает • Проверить CPU/RAM/ DISK queue • Посмотреть статистику запросов • Посмотреть профайлером • Оптимизировать запросы
- 12. 12 Найди затык по графику
- 13. 13 База стала узким местом Временное решение: SSD Решение: Message Queue
- 14. 14 Message Queue
- 15. 15 Message Queue
- 16. 16 Message Queue • В БД пишется только результат • Снижение нагрузки на БД • Масштабируемость
- 17. 17 Message Queue Варианты резервирования: • Холодный резерв VM Replica • Горячий резерв Cluster
- 18. 18 WEB
- 19. 19 WEB • Генерирует контент • Отдает статику
- 20. 20 WEB перестал справляться
- 21. 21 WEB Static
- 22. 22 WEB Static Описание: • Хранит изображения из статей • Конвертирует • При необходимости скачивает с источника • Будет до 2ТБ изображений
- 23. 23 WEB Static
- 24. 24 WEB Static Варианты синхронизации файлов: • На уровне железа (СХД) • На уровне ОС (DFS) • На уровне приложения (Сохранять краулером на все сервера)
- 25. 25 WEB Static Планировали DNS Round Robin
- 26. 26 WEB Static Получилось NLB
- 27. 27 WEB CDN
- 28. 28 WEB CDN • Уменьшает нагрузку на наши сервера • Может иметь странности • Можно положить на тестах
- 29. 29 WEB Balancer
- 30. 30 WEB Balancer
- 31. 31 WEB Balancer Варианты реализаций: • Аппаратный балансировщик • IIS + ARR • Nginx • Haproxy
- 32. 32 WEB Balancer
- 33. 33 WEB Balancer Проблема: Пользователь должен попадать на тот сервер где был раньше Решение: приложение выставляет Cookie
- 34. 34 MongoDB
- 35. 35 CAP Теорема • Consistency (Согласованность) • Availability (Доступность) • Partition tolerance (Устойчивать к разделению) Выберите два
- 36. 36 MongoDB Проблема: SQL не справляется на запись Решение: NoSQL, т.к данные поддаются разделению
- 38. 38 MongoDB проблемы • Backups • Upgrades • BUGS
- 39. 39 Backups
- 40. 40 Backups Админы делятся на тех, кто: • Делает бэкапы • Делает бэкапы в географически разные места(правило 3-2-1) • Проверяет бэкапы
- 41. 41 Как это заливать Все?
- 42. 42 Обычная заливка • Миграции • Сайты • Краулеры
- 43. 43 Заливка Проблема: сложный и неочевидный процесс заливки, правя конфиги Решение: трансформации, скрипты заливки
- 44. 44 Заливка Проблема: монстрообразные скрипты Решение: переход к объектам – можно выбирать что залить
- 45. 45 Monitoring
- 46. 46 Monitoring • Отрицание • Гнев • Смирение
- 47. 47 Monitoring Система лучше или хуже работает после заливки?
- 48. 48 Monitoring А всем ли удобно читать письма?
- 49. 49 Заключение 2012 2014 Серверов 3 60 RAM GB 72 800 SSD GB 200 10 000 MsSQL GB 150 700 MongoDB GB 0 700 Статей за сутки 10 000 150 000
- 50. 50 Спасибо за внимание Гончаров Лев ByndyuSoft ultralisc@gmail.com http://vk.com/ultral
Notas del editor
- Концепт в тестовом окружении превращается в продакшин
- -качаем статьи с инета -анализируем -сохраняем в удобном нам виде -и выдаем пользователю...
- Все решают одну задачу, но у каждого свой бюджет и свое понимание максимальной отказоустойчивости, в нашем случае это означало, что -система может потерять в производительности -может до получаса быть частично недоступна -в случае катоклизма в ДЦ, приелим простой в пару дней
- По мере повестовавния что бы было понятней, расскажу про то как менялся каждый из элементов системы по отдельности, но стоит держать в уме, что это был процесс растянутый примерно на 2 года
- -изначально они были на 2 разных серверах -простой не критичен проблема: из-за переориентации проекта необходим рост поставки с 10-20 тысяч до 200 тысяч решение: развернуть дополнительные краулеры.. автоматизация процесса конфигурирования нового краулера Собираем ошибки в sentry, письмо на почту при эксепшене
- SSD решает
- рассматривалось несколько вариантов -sql mirroing -windows failover cluster - отпад т.к. требует san/nas -alwayson - отпал т.к. надо было развернуться еще вчера, а технология новая и необкатанная hot standby с SQL была проблема, рассматривали вначале автоматическое переключение между серверами, при помощи 3 стороны witness, но т.к. у нас база в асинхронном режиме, то решили использовать скрипт, который переключает в одном направление primary сервер, а восстаналивать потом ручками, вдруг конфликты будут.
- рассматривалось несколько вариантов -sql mirroing -windows failover cluster - отпад т.к. требует san/nas -alwayson - отпал т.к. надо было развернуться еще вчера, а технология новая и необкатанная hot standby с SQL была проблема, рассматривали вначале автоматическое переключение между серверами, при помощи 3 стороны witness, но т.к. у нас база в асинхронном режиме, то решили использовать скрипт, который переключает в одном направление primary сервер, а восстаналивать потом ручками, вдруг конфликты будут.
- проблема: начал тупить сиквел решение: -отлов тяжелых запросов, их оптимизация
- Но проблемы порой не очевидны Оптимизировали запросы по диску, а оказалось, что памяти не хватает
- т.к. отсуствие очереди в течении минут 15 не критично, да и потеря сообщений не страшна, то решили деражть реплику виртуалку и стартовать ее когда настал апокалипсис cold standby -у рабита утекает память, параг гб за пол года, в день десятки млн сообщений На данный момент подумываем о перенастройки кластера hot standby
- первый наш CDN падал, в итоге перешли на cloudfare но там была проблема, что брался один из из списка, в итоге на picture store навешали NLB что бы внешний IP был общий
- IIS – тяжеловесный Nginx – не проверяет когда нода отпала Аппаратный - дорого остановились на связке Haproxy т.к. самый легковесный
- помимо haproxy еще установлен heartbeat, который контролирует, что все IP, на которых весит сайт находятся на живой ноде. т.е. в случае падение одной из проксей, внешний упавшей IP будет авотматически поднят на другой проксе Пришлось компилировать из сорцов т.к. https не поддерживался
- Во время построения индексов монга не отвечает проблема: логи монги сильно растут, блокнотом сложно их смотреть рещение: ротация логов монги бэкапы монги -Снимал снапшотом -> veeam шардинг падает в монге, баг в монге не пофикшенный пересинхронизация
- проблема: бэкапы хранятся в том же ДЦ решение: реализация правила 3-2-1 ТРИ резервные копии, которые должны быть сохранены в ДВУХ различных физических форматах хранения, причем ОДНА из копий, должна быть передана на внеофисное хранение
- Требование заказчика что стг сам деплоится, а хостинг только отвественным лицами
- Кол-во сайтов выросло Кол-во окружений выросло проблема: 2 окружений не хватает, либо тестировать - либо делать новый функционал решение: развертывание 3его окружения staging-preprod-hosting
- проблема: скрипты заливки сильно сложные, сложно вносить изменения в код для разных окружений решение: powershell + ооп , борьба с дублирование
- Система большая стала под 70 серверов, за всем уследить нельяза
- -ничего не мониторить, пользователи сами сообщат когда у них упадет веб/1с -мониторить все что-то только можно и нельзя, оповещать всех, включая не очень заинтересованных что на веб сервере 30 секунд была нагрузка на проц 95% -бизнесу пофиг на процессор/память/диски, больше интересует, лучше или хуже стало после заливки. Надо работать на упреждение в мониторинге велика роль заказчика, только он знает, какие метрики реально важны для бизнеса
- 6 проблема: система что-то делает, но ее эфективность(кол-во статей) можно посомтреть только SQL запросом решение: мониторить поставку
- 8 проблема: сильно много алертов в скайпе решение: не обязательно писать все подряд, бизнесу пофиг что проц в 100% главное что статьи качаются проблема: есть пропуск значений при мониторинге решение: не заббикс собирает данные, а забиксу их шлет, можно делать тяжелые запросы теперь
- Изначально это было 3 пк под столом, Стало 7 серверов в ДЦ Планируйте Держите руку на пульсе Запаситесь терпением