Как гласит старинная шутка, системные администраторы делятся на две группы: те, которые не делают бэкапы, и те, которые уже делают бэкапы. Систем резеревного копирования существует великое множество, от простейшего самописного скрипта до огромных монстров ценой в “боинг”. Все системы нужны для разных целей и выполняют разные задачи.
Согласно статстике W3Tech 98.5% современных сайтов – это динамические сайты. Строго говоря – это программы (порой – большие и сложные программы), мощные многоэтажные системы, связаные со сложными системами хранения данных. Каждое посещение такого сайта – это выполнение кода, что требует ресурсов сервера и времени. При этом реально в большинстве случаев вся эта мощь не используется – большинство сайтов довольно компактные и редко обновляются. А значит – мощная, сложная, гибкая, многокомпонентная, что самое страшное – потенциально ненадежная система, в общем-то, не нужна.
Перевод сайта с динамики на статику – это простой и удобный способ обойтись без сложностей, не потеряв гибкости и удобства.
MySQL - сверх-популярный сервер баз данных. Его используют (или использовали) практически все. Одна из самых популярных задач в системном администрировании - бэкап (и восстановление). Или, как подвид - миграция данных (бэкап + последующее восстановление). Это делают практически все. И практически все используют для mysql_dump, что категорически неправильно и часто просто опасно. В этой статье я расскажу, почему mysql_dump - это плохое решение и что с ним можно сделать.
PHP - исключительно популярный язык программирования, до сих пор огромное количество проектов пишется именно на нем. Язык ругают за отвратительный дизайн, неудобный синтаксис, кривое поведение в спорных случаях, отсутствие нормальных средств отладки - но его популярность это никак не снижает. Самое страшное для админа - ситуация, когда на сильно нагруженном проекте начинает тормозить код. Стандартные средства отладки (xprof, xdebug) роняют производительность языка в яму (накладные расходы - вплоть до пятикратного падения скорости), и как отлаживать сложный код на живую - совершенно неясно. Именно для борьбы с такими проблемами придумана PINBA - расширение для мониторинга скорости кода. Тут я расскажу, как установить PINBA (клиент, сервер и интерфейс) на debian и что с ними потом делать.
По сути - это не статья, а, скорее, просто памятка, чтобы самому не забыть. MongoDB - популярный документо-ориентированный движок управления базой. Штатно он имеет две разных технологии кластеризации: репликационные наборы (replica set) и шардирование (shard). Разница проста - в случае реплики на всех узлах данные одинаковы и любой узел может выступать источником данных (внимание, mongodb не является CAP-полной базой, так что точность данных тут под большим вопросом!), что обеспечивает отказоустойчивость. В случае шардирования данные “размазаны” по всему набору шарда, но каждый сервер внутри шарда имеет только свои данные. За счет этого распределяется нагрузка (например, с трех узлов данные можно читать параллельно), но снижается надежность - упавший узел означает потерю части данных шарда. В данной статье будет описание, как переехать с единичной монги на репсет не потеряв при этом данные.
MySQL - одна из самых ходовых, распространенных и простых во внедрении СУБД. Этот СУБД использует, наверное, половина всех проектов веба. Исключительная простота установки и внедрения, распространенность, поддержка “из коробки” во всех ходовых языках программирования для веб (perl, PHP, ruby, python, JS/node). Из-за мнимой простоты внедрения на потенциальные проблемы внедрения внимания просто не обращают - 90% проектов не доживут до того момента, когда заботливо разложенные авторами MySQL грабли больно ударят по лбу.
Одна из серьезных грабель MySQL - серьезные проблемы с производительностью и надежностью. Тюнинг MySQL сложен, так, как изначально MySQL задуман для быстрого внедрения в небольшом проекте. Кроме того, имея серьезный, высоконагруженный проект, хочется снизить риск отказа базы данных (согласно закону Паркинсона, все, что может сломаться - сломается, и частно - в самый неудачный момент). В данной статье я распишу, как мигрировать одиночный MySQL на кластер из трех равновесных машин (для надежности - отказ любого сервера не оставит вас без базы) с автоматическим распределением нагрузки.
Современные жесткие диски - чудо инженерии и техники. Пластины из магниево-алюминиевого сплава несутся со скоростью 120 оборотов в секунду, при этом считывающую голову от поверхности диска отделяет расстояние в 1/10 толщины человеческого волоса. Сама голова перемещается в любую точку всего за 2мс, что вызывает боковую перегрузку в фантастические 550G. Современные диски обладают впечатляющим объемом, большой линейной скоростью (что на чтение, что на запись) и минимальной задержкой поиска. И платят они за это (кроме цены) серьезным падением надежности. Старенькие Seagate Barracude и Quantum Fireball 6-10 гигабайт объемом без каких-либо нареканий жили десятилетиями, еще более старинные IBM на сотни мегабайт можно было безопасно вскрыть и закрыть в домашних условиях без специальной подготовки. Современные модели крайне чувствительны к вибрациям, тряске, углу наклона, удару и даже шуму (sic!). Средний срок жизни современного террабайтника - три года, если он эксплуатируется не слишком активно. Диски для серверов и NAS живут год-два. Если раньше RAID считался дорогой экзотикой серверного мира (по типу SCSI), то сейчас программный soft-raid - абсолютная необходимость, без которого сервер просто нельзя устанавливать.
Как-то мне (в очередной раз) потребовалось настроить мониторинг доступности клиентского сервиса через интернет. В процессе настройки я обнаружил, что не смотря на существование очень простого, понятного и удобного инструмента под названием SmokePing, по нему практически нет документации на русском (а документация на английском очень ограничена и запрятана в странном месте). Поэтому я решил написать эту небольшую вводную статью.
Кто-то, возможно, не поверит, но написать эту статью я собирался довольно давно. Недавние события (утечка личных фотографий звезд и 7 миллионов почтовых паролей от google и yandex) не была поводом, но подтолкнула меня к перу. Безопасности в интернете (и вообще - в ИТ) обычный пользователь уделяет на диво мало внимания, не в пример безопасности физической. Кто-то не хочет ничего делать потому, что лень, кто-то считает, что ему “как честному человеку скрывать нечего” (да-да, я встречал такой лозунг неоднократно, особенно, когда вводили цензуру в интернете на территории 1/5 части суши).
Мониторинг (отслеживание состояния сервисов), наряду с резеврным копированием является, наверное, одной из самых старых и популярных задач для системного администратора. Разумеется, существует великое множество различных инструментов для ее выполнения. В этом развесистом великолепии с трудом ориентируются даже бывалые специалисты. В данном тексте я собрал основные системы мониторинга с кратким описанием и сравнением плюсов, минусов и особенностей. Разумеется, статья не претендует на всеобъемлющее описание всех систем мониторинга планеты (их слишком много), но поможет хотя бы соориентироваться и понять, куда искать.