- Новосибирск, Россия
- (+7 383) 212-72-73
- sale@anz.ru
Установщик дистрибутива Ubuntu-server устанавливает и включает ряд сервисов, которые никогда не понадобятся, если вы ставите его в качестве персонального виртуального сервера с малым объёмом оперативной памяти. Эти сервисы постоянно находятся в памяти, и будет лучше их удалить или выключить.
1. Snapd — менеджер пакетов snap. Если вы не будете его использовать, лучше его удалить:
apt purge snapd,squashfs-tools
Если пакеты snap когда-нибудь понадобится установить, то пакет легко вернуть на место:
apt install snapd
2. ModemManager — менеджер USB-модемов. Для персонального виртуального сервера не нужен, отключаем:
systemctl stop ModemManager
systemctl disable ModemManager
3. DM-Multipath — DM-Multipath позволяет объединить несколько маршрутов ввода-вывода между серверами и дисковыми массивами в единое целое. Предназначен для агрегации нескольких физических сетевых накопителей в одно устройство. Для VPS с одним диском не нужен. Останавливаем и отключаем демон multipathd:
systemctl stop multipathd
systemctl disable multipathd
4. udisks2 — демон и утилиты для подключения съёмных устройств, различных USB-накопителей. Для VPS его необходимость сомнительна, отключаем:
systemctl stop udisks2
systemctl disable udisks2
В работе над настройкой движка форума phpbb была задача — сделать два совместно работающих сервера web-приложений. Серверы разного поколения (HP gen 9 и HP gen 8), соответственно, разные процессоры, разное число ядер и памяти.
На более мощном сервере размещается nginx, и первый сервер приложений. В nginx имеются широкие возможности для создания балансировщика нагрузки между серверами приложений. Если приложение штатно не поддерживает работу в кластере, лучше использовать режим балансировки ip_hash, в nginx есть соответствующая директива. Что происходит при таком режиме работы — пришел первый запрос с какого-то IP-адреса. Nginx проксирует его на один из серверов приложений, согласно весу (директива weight). После чего сессия, сеанс связи, будет только на этом сервере, nginx не будет перекидывать пользователя между серверами приложений. Пример такой настройки дан ниже. Для «развесовки» серверов я использую число ядер cpu на каждом из них.
upstream phpbb_cluster {
ip_hash;
server 192.168.100.2:8443 weight=32 max_fails=0; # Первый сервер приложений с весом 32
server 192.168.100.4:8443 weight=40 max_fails=0; # Второй сервер приложений с весом 40
}# Ниже, в секции конкретного сайта (server), где запрос передается апстриму:
location @fallback {
proxy_pass https://phpbb_cluster;
}
Nginx так же обрабатывает все запросы, связанные со статикой (картинками, видеофайлами, ява-скриптами, таблицами стилей и прочее), отдавая серверам приложений только обработку, собственно, скриптов php.
Важно то, что ресурсы обоих серверов должны быть общими. Как можно выйти из положения — на самом мощном сервере хранятся все файлы. Статика должна храниться там, где запущен nginx. Скрипты сайта хранятся там же. Их мы отдаем другим серверам приложений по NFS. Параметр RPCNFSDCOUNT, задающий число потоков RPC NFS, должен быть большим, порядка 500 — 1000. Приоритет сервера задается параметром RPCNFSDPRIORITY, можно задать от -5 до -12.
Второе важное замечание касается кеша приложения. Он должен быть раздельным для разных серверов, иначе будут сыпаться ошибки о правах доступа к файлам, серверы будут пытаться создавать кешируемые файлы поочередно, в директории cache в корне сайта, если, конечно, для кеширования используется драйвер file из phpbb/cache/driver).
Можно было бы выйти из ситуации, храня кеш в базах данных memcached, redis, или использовать xcache, но в состав phpbb входит движок темплейтов twig, который тоже создает свой кеш в той же директории cache, а он ни с чем, кроме файлов, работать не умеет.
Избежать этой проблемы можно. Когда монтируем NFS каталог с главного сервера на остальных серверах приложений, надо затем смонтировать в директорию cache локальную директорию, например /tmp/cache, с опцией bind. В этом случае кеши на разных серверах приложений будут свои. После этого форум phpbb или сайты, построенные на его основе будут работать без проблем на двух, трёх и более серверах приложений php-fpm.
Во всех непонятных ситуациях СМОТРИТЕ ЛОГИ. Все проблемы скрываются там.
Обязательно синхронизируйте время сервера с серверами точного времени, если есть кластер — создайте свой сервер точного времени, который синхронизируйте со внешними. В роутерах mikrotik для этого есть пакет ntp, с его помощью можно синхронизировать время всей локальной сети. Синхронизация времени поможет работать с логами, разбираться с событиями на разных серверах кластера.
Если логи недостаточно информативны — включайте расширенное логирование в настройках конкретных сервисов.
Логи — главное ваше оружие в поисках и уничтожении проблем.
В связи с реорганизацией нашего банка у нас изменились банковские реквизиты. Узнать обновленные реквизиты можно на странице контактов.
Мы разместили у себя одну из точек мониторинга сервиса Ping-Admin.ru. Ping-Admin.ru — профессиональный мониторинг сайтов и серверов. Ping-Admin.ru осуществляет круглосуточный мониторинг доступности и проверку работы на сервере ряда сервисов, а кроме этого регулярно проверяет срок действия SSL-сертификатов, срок действия доменов, SEO-ссылки, осуществляет проверку сайта на вирусы, проверку наличия домена и IP в чёрных списках, мониторинг внутренних ресурсов сервера (нагрузка, жёсткий диск, uptime и прочих).
По мнению специалистов этого ресурса, наш датацентр признан одним из самых надежных, а сотрудничество такого сервиса с нами является негласным признанием и нашей надежности. Вот проверка нашего сайта с использованием средств этого сервиса. Наши специалисты технической поддержки рекомендуют использовать нашим клиентам именно этот сервис мониторинга, ведь его точка размещена у нас, значит мониторинг будет осуществляться с минимумом задержек и не будет зависеть от промежуточных узлов сети Интернет.
Мы призываем и другие сервисы сотрудничать с нами на взаимовыгодных условиях.
Наши серверы стоят в дата-центре компании «Ростелеком». Чтобы контролировать, настраивать, администрировать их из нашего офиса, мы используем связь с роутером и межсетевым экраном в дата-центре по шифрованному каналу IPsec. В нашем офисе мы используем хорошо себя зарекомендовавшую модель Zyxel Keenetic Ultra II — универсальное решение с аппаратным криптомодулем и аппаратными разгрузками NAT и контрольных сумм. Кроме того, в совокупности с модулем Keenetic DECT Plus этот роутер обслуживает и нашу IP-телефонию. Сегодня мы обсудим связку этого роутера и роутера Mikrotik RB1100AHx2, который мы в настоящее время используем в дата-центре.
Дано (все белые IP вымышлены):
Конфигурация RB1100AHx2
Белый IP-адрес WAN-интерфейса 152.12.12.12
Внутренняя сеть 192.168.10.0/23
Конфигурация Keenetic Ultra II
Белый IP-адрес WAN-интерфейса 182.12.12.12
Внутренняя сеть 192.168.80.0/24
Обязательное условие — внутренние сети не должны пересекаться!
Настройка Mikrotik:
Прежде всего идем в IP -> IPsec -> Groups, если там нет ни одной группы, просто жмем плюсик «Добавить», в открывшемся окне, в поле «Name» пишем «default» и жмем Ok, проще говоря добавляем группу default. Иначе в дальнейшем будут глюки при установлении соединения в фазе 1, дело в том, что темплейт policy по умолчанию должен принадлежать какой-то определенной группе. Иначе в поле «Policy Template Group» первой фазы (в настройке Peer) будет значение unknown, а связь не будет устанавливаться. Похоже на какую-то магию, но OS закрытая, доступа к внутренностям у нас нет, что там происходит сказать нельзя, так что просто добавляем группу, если ее нет, и идем дальше.
Добавляем Policy, для чего идем в IP -> IPsec -> Policies, жмем плюсик «Добавить»
Policy — это правило, что именно нужно делать при пересылке данных между подсетями, которые мы указываем на вкладке General. Source Address — локальная сеть в дата-центре, обслуживаемая роутером Mikrotik RB1100AHx2. Destination Address — локальная сеть в офисе, которую обслуживает Zyxel Keenetic Ultra II. Галочку «Template» не ставим, она превращает Policy в темплейт, а нам нужна именно Policy.
На вкладке Action мы указываем действие, которое должно происходить, мы хотим шифровать данные в туннеле (галочка Tunnel), туннель устанавливается между WAN-интерфейсами обоих роутеров, на которых прописаны белые адреса, которые участвуют в создании Security Association (SA), SA Src. Address (белый IP RB1100AHx2), SA Dst. Address (белый IP Keenetic Ultra II). Данные шифруются так, как указано в default proposal.
Далее настраиваем первую фазу IPsec — идем в IP -> IPsec -> Peers, жмем плюсик «Добавить»
Тут настроек уже больше. Address — IP-адрес удаленного роутера, вписываем туда белый IP Keenetic II Ultra. Port — обычный порт ISAKMP, менять его не стоит. Local Address можно не указывать. Придумываем ключ PSK, вписываем в поле Secret, где-нибудь его временно сохраняем — он понадобится, когда будем настраивать Keenetic UItra II. Устанавливаем галочку NAT Traversal, чтобы с роутером смогли связаться устройства, расположенные за NAT. Далее выставляем необходимые алгоритмы шифрования. Аппаратно обоими роутерами поддерживаются хеширование SHA1 (недавно был-таки взломан неутомимыми сотрудниками Google, а еще раньше не менее работоспособными китайцами), SHA256 и шифрование AES128-CBC, AES192-CBC, AES256-CBC — можно указать их все, при установлении SA обычно выбирается максимально возможные алгоритмы. Lifetime — время жизни ключа, по окончании действия ключа он будет перегенерирован. DPD или Dead Peer Detection — своеобразный keepalive, проверка удаленного peer, раз в какое-то время (DPD Interval) устройства спрашивают друг друга «ты там как, жив?» (R-U-THERE), ответ должен быть «да, живой я» (R-U-THERE ACK).
Если ответа нет, инициатор переспрашивает некоторое количество раз (DPD Maximun Failures), после чего уничтожает IPsec-сессию, и удаляет обе SAs. После этого устройства будут пытаться восстановить связь, если это прописано в настройках. При DPD Interval «disabled» ключ не будет обновляться в первой фазе при достижении конца Lifetime, так что лучше в этом поле выставить некое значение. DH Group это группа Диффи-Хеллмана, соответствия этих modp номерам в Keenetic есть в этой таблице.
Настройка второй фазы IPsec — идем в IP -> IPsec -> Proposals. Там уже есть default proposal, он был указан при создании Policy, так что можно просто подогнать его под себя. Помним об алгоритмах, обрабатываемых аппаратно, имеет смысл выставить именно их, при использовании аппаратного критомодуля загрузка процессоров обоих роутеров стремится к нулю.
Здесь тоже есть поле Lifetime, по окончании которого ключ будет перегенерирован. Здесь это происходит всегда, в отличии от первой фазы.
Открываем терминал и добавляем правило, разрешающее прохождение пакетов в обход маскарадинга (помним, какие сети мы разрешили в policy):
/ip firewall nat add src-address=192.168.10.0/23 dst-address=192.168.80.0/24 action=accept chain=srcnat comment=»To Office»
Ставим его над маскарадингом, на первое место:
/ip firewall nat move [find comment=»To Office»] 0
На этом настройку Mikrotik можно считать завершенной. Приступаем к
Настройке Keenetic Ultra II
Заходим в WEB-интефейс роутера, в самом низу его находим кнопку со щитом — раздел «Безопасность». Нажимаем ее, ищем вкладку IPsec VPN. Если ее там нет (вот неожиданность!) — идем в раздел Система (кнопка с шестеренкой) -> Обновление, жмем кнопку «Показать компоненты», ищем в списке IPsec VPN и ставим рядом с ним галочку, жмем в самом низу кнопку «Установить». Обычно он устанавливается сразу. Если серверы NDMS живы. Иногда надо подождать, но когда-нибудь вы его установите, если будете достаточно терпеливы.
Компонент установился? Роутер перезагрузили? Он делает это не торопясь, основательно, наверное тщательно расставляет каждый бит по ячейкам памяти… Но вот наконец, снова идем в раздел безопасность и находим-таки там вкладку IPsec
Ставим галочку «Включить», жмем кнопку «Применить». В IPsec-подключениях сначала будет пусто, жмем кнопку «Добавить». Возникнет окно настройки IPsec-подключения
Вписываем имя соединения. Выставляем галочки «Включить» (мы же все еще хотим установить соединение с mikrotik?), Автоподключение, Nail up (для удержания соединения), «Обнаружение неработающего пира (DPD)», задаем необходимый интервал проверки.
В поле «Удаленный шлюз» вписываем белый IP-адрес Mikrotik.
Далее настраиваем фазу 1. Мне лично не удалось заставить работать эти два роутера с протоколом IKE v2, поэтому все настройки приведены для IKE v1. У нас в офисе белый IP-адрес, грех не сделать его идентификатором локального шлюза. Поскольку мы указали белый IP-адрес Mikrotik, то в поле «Идентификатор удаленного шлюза» можно поставить «Any», или «IP-адрес», так же в нашем распоряжении есть три отлично работающих DNS, соответственно все устройства имеют корректные доменные имена, мы могли бы использовать в качестве идентификатора и FQDN. Помните, мы при настройке Mikrotik RB1100AHx2 придумывали ключ PSK, так вот, самое время его вписать в поле «Ключ PSK», кстати, оглянитесь, за плечами у вас нет врагов? Ключ прямо так и будет виден.
Хеш, алгоритмы шифрования и группу Диффи-Хеллмана надо выставить точно такие же, как и на Mikrotik, в настройках Peer, иначе роутеры не смогут друг с другом договориться. Режим согласования лучше оставить Main, Aggressive хоть и ускоряет подключение, но менее безопасен, например ключ передается не по шифрованному каналу, а по открытому, в виде хеша, а мы же зачем-то тут настраиваем IPsec… Так мы плавно перешли к настройке фазы 2
Режим задаем, конечно, туннель, ведь именно IPsec-туннель мы все это время и настраивали. Алгоритмы шифрования, хеши и группа Диффи-Хеллмана здесь должны соответствовать настройкам Proposal в Mikrotik. Вписываем локальную и удаленную подсети в соответствующие поля. Жмем «Применить».
Если все сделали правильно — пойдет инициализация соединения, в логах Mikrotik не должно быть ошибок, в IP -> IPsec -> Remote Peers должен образоваться Peer:
А в IP -> IPsec -> Installed SAs появиться две Security Associations, и должен быть виден обмен данными:
На стороне Keenetic весь процесс соединения отображается в логе, а информацию о соединении мы увидим на странице «Системный монитор» и вкладке «IPsec VPN»:
Со стороны Keenetic можно попробовать достучаться до какой-либо из удаленных машин.
Всем привет! Да-да, свершилось: у нас новый сайт! 10 лет мы жили со своим любимым, понятным и ставшим таким родным сайтом, который когда-то сделали сами ? Но время идет, и если сначала мы шутили, что наш сайт показывает нашу стабильность и непотопляемость, то в последнее время всё больше клиентов и партнёров стали обращать внимание на архаичность нашего сайта. Пришлось взять волю в кулак, сдержать слезу и создать новый корпоративный сайт. Этот сайт мы тоже сделали сами. Получилось симпатично и современно. Мы постарались сделать меню нашего сайта очевидным и простым. В общем, добро пожаловать на обновлённый сайт компании «Аэнзет»!
Команда A&Z
