Можно прочитать много книг по базам данных, написать кучу приложений на аутсорс или для себя. Но при этом невозможно не наступить на грабли, при работе с действительно большими базами/таблицами особенно, когда downtime на большом проекте хочется свести к минимуму, а еще лучше совсем избежать. Вот здесь самые простые операции, как например изменение структуры таблицы может стать более сложной задачей. Наиболее интересные случаи, проблемы, грабли и их решения из личного опыта с которыми нам на проекте Pushwoosh пришлось столкнуться описаны под катом. В статье нет красивых картинок, зато есть много сухого текста.

После выхода mysql 5.6 с его GTID (global transaction identifier) репликация в mysql перестала быть кошмарным сном сисадмина и стала вполне рабочим инструментом. В инете есть некоторое количество информации по этому поводу, но вся она довольно разрозненная и не всегда доступна для понимания. По этому я решил сделать небольшую инструкцию-выжимку, больше для себя, но может и еще кому пригодится.

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Книги.
Я считаю, что важнейшим инструментом получения скилов системного администрирования являются именно они — книги.
Нет специальных факультетов, обучающих «админству» — каждый постигает это самостоятельно. Путем проб, ошибок и боли, потере важных данных различных злоключений.
В начале пути сложно определиться, что же нужно прочесть — ведь массив информации столь огромен!
В данном посте я хочу собрать наиболее важные и значимые труды для системных администраторов.
Уклон будет на *nix админство, но, надеюсь тема окажется небезынтересной и для Windows коллег и в комметариях они заполнят мои пробелы.
Пост субьективен и отражает лишь мой собственный опыт — я раскажу о книгах, которые помогли моему становлению.

Введение

Если вы когда-либо задумывались о шифровании данных на дисках уже после того, как у вас накопилось их приличное количество, вы, вероятно, расстраивались, прочитав о необходимости переноса данных перед созданием шифрованного раздела и после. Перенос 500 ГБ туда и обратно не представляет никакой особой трудности, такой объем можно временно загрузить даже в облако, но если речь идет о шифровании 6 винчестеров по 4 ТБ каждый, задача заметно усложняется. По какой-то причине, возможность шифрования и перешифровывания томов LUKS без потери данных (in-place re-encryption) слабо освещена в интернете, хотя для этого есть две утилиты: cryptsetup-reencrypt, входящая в состав cryptsetup с 2012 года, и сторонняя luksipc, появившаяся на год раньше. Обе утилиты выполняют, в общем-то, одно и то же — шифруют раздел, если он не был шифрован, либо перешифровывают уже существующий с другими параметрами. Для своих нужд я воспользовался первой, официальной.

Как это работает?

Предположим, у вас типичная разметка диска: один раздел, начинается с 1 МиБ (выравнивание для 4КиБ-секторов), заканчивается в конце диска.


Заголовок LUKS располагается в начале, перед зашифрованными данными. Для заголовка требуется минимум 2056 512-байтных секторов, т.е. чуть больше 1МиБ. Места перед началом раздела нам явно недостаточно, поэтому сначала нужно уменьшить размер файловой системы с ее конца, чтобы cryptsetup-reencrypt перенес блоки правее, в конец диска, освободив таким образом место в начале раздела для LUKS-заголовка. Конечный размер заголовка зависит от длины ключа, количества слотов для парольных фраз и прочих параметров, поэтому я рекомендую быть рачительным и отвести под заголовок 4 МиБ.

Не знал где это написать, думаю на хабре будет самое место. Везде пишут что fsarchiver — замечательная утилита, что может создавать архивы с файловой системой, хорошо их сжимает и т.д. И это действительно так! И самое главное что эти архивы можно деалать на работающих системах.

Но вот сегодня выходной день, сервера находятся в другом городе и один из них лег, на системнике лампочка с восклицательным знаком горит красным цветом, а значит тяжелая беда с железками. По удаленке поднять не можем. С сервером конечно разберемся и починим, но надо скорее поднимать сервис на резервной машине. Образы всех серверов конечно мною были заботливо сделаны при помощи замечательной утилиты fsarсhiver.
И вот встала задача как достать конфигурационные файлы из fsa-образа.

Продолжая тему, описанную здесь habrahabr.ru/post/252973, опять пишу про увеличение дисков виртуальных машин.
Конфигурация следующая:
Гипервизор сервер Supermicro с KVM и libvirt на Ubuntu.
Гости — Ubuntu с LVM2.
Задача:
Увеличить размер системного дисков без выключения/перезагрузки гостевой ОС.

В комментариях к предыдущей статье habrahabr.ru/post/252973/#comment_8330673 farcaller написал:

Системный тоже можно на лету отресайзить. Для этого в libvirt есть команда:
virsh qemu-monitor-command resized-virtual-machine --hmp «block_resize $DRIVENAME $NEWSIZE»

Для HA проектов это очень важный момент, необходимо непрерывное функционирование сервиса.
Я решил попробовать изменить размер диска при помощи virsh.
Ниже результаты этого успешного эксперимента.

Давайте сразу начистоту: никто не любит платить за софт много. И для некоторых «много» — это всё, что больше цены ежедневного обеда. Даже когда речь идёт о профессиональном ПО для профессионалов, если на горизонте возникает чуть менее платный конкурент с меньшим количеством функций, он сразу же привлекает к себе множество внимания, а в головах изумлённой публики возникает вопрос: «А может, в признанном лидере рынка действительно уже перебор этих самых функций, и платить за них нет никакой причины?». В качестве ответа, некоторые производители начинают искать новые, относительное честные методы отъёма денег у населения, и вводят подписочные сервисы, которые в первом приближении, позволяют платить за софт намного меньше.

Другой подход к проблеме — чёткое понимание, какой функционал нужен на уровне домашнего и/или лабораторного использования, а какой на уровне больших корпораций. И после того как дзен постигнут, весь “домашний” функционал становится бесплатным, а за остальное просят денежку.

Сегодня предлагаю вам рассмотреть именно вторую модель, выяснив, что же компания Veeam предлагает своим пользователям на безвозмездной основе и так ли этого мало для ежедневного личного использования. Пусть даже если из-под “личного” проглядывает небольшая купи-продай контора, или простихосподи, стартап, который считает, что «кровавый вендор» хочет слишком много денег за свои продукты.
Если сомневаетесь, что они дают действительно мощные инструменты, не прося ничего взамен и что вообще так бывает — добро пожаловать под кат.

Вдохновленный публикацией «Выжимаем все соки из бесплатной версии Veeam Backup & Replication», я решил написать свой HowTo как по-полной задействовать Veeam.



Это не рекламная статья, тут нет тысячи и одного красочного скрина. Так же это не обзор продуктов, коих и так достаточно. Просто полезная информация как полноценно использовать бесплатные решения от Veeam в корпоративной среде. Сухие команды и подсказки. Все описанное ниже это мой личный опыт и, местами, ссылки на представителей Veeam, официальный форум и хабраюзеров.

TL;DR

Чтобы просто установить и изолировать зависимости проекта, virtualenv часто оказывается слишком тяжелым решением. Предлагаем простую альтернативу:

1. добавить ./.pip в переменную окружения PYTHONPATH,
2. установить пакеты локально с помощью pip install -t .pip,
3. запускать python из папки проекта.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Шифруем всё подряд

Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.

Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.

Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.

То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.

Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.

Снова тема VPN, конфиденциальной передачи данных, безопасности и криптографии. Сейчас, в эру пост-Сноудена, стало модно клепать безопасные, уважающие приватность, невзламываемые, защищённые от спецслужб и цензуры программы. Однако эта статья – не очередной маркетинговый пиар, а, скорее, демонстрация того, как применяются криптографические примитивы и на что стоит обращать внимание при разработке подобного программного обеспечения.



Результатом этой работы предполагается создание работающего клиент-сервера, пригодного для review разработчиками (то есть немного кода на высокоуровневом языке), достаточно производительного, чтобы использоваться в промышленных условиях, имеющего высокий порог безопасности: GoVPN.

Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).

В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.



Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…

Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.

Прошло полгода с момента анонса решения Veeam Endpoint Backup Free на конференции VeeamON. За это время мы успели выпустить бета-версию продукта, раздать ее примерно 20 тысячам человек и провести с их помощью масштабное тестирование, чтобы выявить «детские болезни» программы. Ну а сегодня, мы с радостью представляем финальную версию программы.

С помощью программы вы можете сделать резервное копирование вашего компьютера, его томов (дисков) или же просто файлов и папок. А затем восстановить ваши данные при сбое системы, неисправности жесткого диска, повреждении или случайном удалении файла.

Для тех, кто пока не нашел время посмотреть, что же продукт из себя представляет, я подготовил обзор его основных возможностей и всяких полезных мелочей. Добро пожаловать под кат.

Сначала мы познакомимся с udev и научимся с его помощью исследовать установленные в компьютере устройства прямо во время загрузки: в качестве примера будем автоматически выбирать настройки видеокарт для Xorg. Затем решим задачу работы с одним образом на десятках компьютеров одновременно путём внедрения собственного обработчика в initramfs, а заодно оптимизируем систему для сетевой загрузки. Чтобы дополнительно уменьшить время загрузки и снизить нагрузку на сеть попробуем NFS заменить на NBD, и помочь TFTP с помощью HTTP. В конце вернёмся в начало — к загрузочному серверу, который также переведём в режим «только для чтения».



Данная статья — скорее исследование, а не готовое руководство (все решения работают, просто они не всегда оптимальны). В конце у вас появится достаточно знаний, чтобы сделать всё так, как захотите именно вы.

Начало смотрите здесь:
Первоначальная настройка сервера
Подготовка образа для загрузки по сети

Мы продолжаем серию статей про взаимодействие Linux и Windows. Эта статья посвящена управлению доступом к серверам Samba из домена AD.

В отличие от предыдущих статей, где в качестве примера использовалась тестовая сеть, эта статья базируется на реальной, «боевой» сети Московского энергетического института. В сети МЭИ зарегистрировано около 25000 пользователей. Сеть объединяет все учебные корпуса МЭИ с более чем 4500 рабочими станциями. Мы рассмотрим настройку доступа к серверу Samba, предоставляющему пользователям следующие услуги:
•доступ к персональному каталогу пользователя;
•доступ к общим каталогам;
•управление доступом как с использованием средств Samba, так и с использованием средств Windows.

Доброго времени суток, уважаемые читатели!
В этой статье я хочу рассказать вам о технологии балансировки нагрузки, немного об отказоустойчивости и как все это подружить с контейнерами в OpenVZ. Будут рассмотрены основы LVS, режимы работы и настройка связки LVS c контейнерами в OpenVZ. Статья содержит в себе как теоретические аспекты работы данных технологий, так и практическую часть — проброс трафика от балансировщика внутрь контейнеров. Если это вас заинтересовало — добро пожаловать!

Итак, у вас есть нагруженный сервер и вам вдруг захотелось его разгрузить. Вы поставили и залили такой же (такие же), но пользователи упорно ходят на первый. В этом случае конечно же нужно задуматься о балансировке нагрузки.

На волне популярности Docker на Хабре, после участия в некоторых дискуссиях в комментариях относительно Docker, и в связи с недавней необходимостью настроить централизованную авторизацию для кластера Linux машин, я решил написать небольшую заметку. Здесь будет показан яркий, на мой взгляд, пример применения Docker'a для небольшой частной задачи.

Вот так, кстати, выглядит FreeIPA WebUI (официальное демо) (кликабельно):



Какие задачи я хотел решить при помощи FreeIPA:

1. Иметь возможность создавать/изменять/удалять акаунты пользователей централизовано, а не на каждом отдельном сервере
2. Централизованные плавила для sudo
3. В последствии мы подключим к этой системе ещё и VPN авторизацию, а потом может и другие внутриофисные сервисы

Да, скорее всего FreeIPA в нашем случае это выстрел пушкой по воробьям, но с другой стороны — альтернатив что-то не видно. Я рассматривал такие варианты: NIS (по-моему он уже давно должен отправиться на отдых), OpenLDAP +… +… (не очень дружелюбно, да и FreeIPA в итоге под собой имеет LDAP, только нам не приходится с ним иметь дело напрямую), тут перечень заканчивается, я не нашёл ничего больше.