Соединение двух серверов asterisk между собой

Введение

Устанавливать Asterisk 16 на Centos 8 будем из исходников. Это не для того, чтобы показать олдскул и крутость самостоятельной сборки софта. Это вынужденная мера. Всегда, когда есть возможность установить из пакетов, лучше ей воспользоваться. Либо можно собрать свой пакет и ставить уже из него. Сборка софта из исходников крайняя мера, когда готового пакета просто не существует.

Я устанавливаю версию 16, хотя есть уже 17-я. Именно 16-я версия имеет статус LTS, то есть длительная поддержка. Если вам не нужны новые фичи промежуточных версий, рекомендую всегда ставить lts версии.

Для установки Asterisk 16 на свежую Centos 8 я не нашел репозитория, где бы были собраны все пакеты с зависимостями для быстрой и безпроблемной установки. Так что будем по старинке собирать все руками. Ничего сложного тут нет. Все примерно так же, как и в прошлых версиях. Каких-то новых сложностей или нюансов я не заметил.

Если у вас еще нет готового сервера, то рекомендую мои статьи по установке и настройке Centos.

Для отладки и тестирования работы voip я рекомендую сервис Zadarma. Плюс его в том, что после регистрации вы получите настройки пира для внутренней сети оператора. И внутри этой сети вы можете бесплатно звонить. Например, я одного пира регистрирую на sip клиенте смартфона и с него звоню на второй аккаунт, пир от которого настроен в астериске. Таким образом эмулирую внешний звонок. Удобно отлаживать различные конфигурации звонков, не требуя платного подключения.

Перенос или восстановление linux сервера

Представим теперь ситуацию, что наш веб, или какой-нибудь другой сервер умер, и нам надо восстановить систему в другом месте. Выполним полное восстановление всего сервера с помощью созданной ранее резервной копии. Для этого нам понадобится Veeam Linux Recovery Media, который мы скачали ранее.

Для восстановления системы нужно соблюсти два обязательных условия:

Готовим новый сервер с диском, который должен быть не меньше диска исходного сервера. Это обязательное условие, иначе восстановление системы даже не начнется. Veeam скажет, что размер диска недостаточный и не предложит больше никаких вариантов восстановления.
Оперативной памяти для системы должно быть не меньше 1024 Мб. Если меньше, то загрузка с диска не будет выполнена. Система скажет, что она не может развернуть корневой раздел.

Загружаемся с диска. В разделе Configure network убеждаемся, что сеть настроена, получен ip адрес, который имеет доступ к интернету. Далее выбираем Restore volumes -> Add shared folder. Заполняем параметры доступа к хранилищу архивов.

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

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

У меня слева чистый диск, справа тоже один диск, на который установлен загрузчик и есть один раздел с корнем системы. Выбираем справа наш диск (не раздел с корнем!!!) и жмем Restore whole disk to.

В качестве приемника выбираем пустой диск на новом сервере.

Нажимаем S ( Start restore ). Визард покажет список действий, которые будут выполнены и попросит их подтвердить, нажатием на Enter.

Делаем это и наблюдаем за процессом восстановления сервера centos из бэкапа.

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

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

Переключение на новый сервер

Самый важный и ответственный этап переноса почтового сервера. Здесь нужно еще раз хорошенько все проверить, убедиться, что все работает нормально. Непосредственно перед переключением на новый сервер, можно еще раз накатить изменения почтовой базы без остановки старого. Это позволит максимально уменьшить время простоя. Когда все готово, останавливаем службы dovecot и postfix почтового сервера. После этого сразу же запускаем синхронизацию каталогов между старым и новым сервером. Мы накатываем все изменения почтовой базы, делая ее полностью актуальной в новом сервере. Для этого надо добавить ключ —delete к rsync.

# /usr/bin/rsync --delete -av [email protected]:/data/mail /data

Важно не перепутать источник с приемником. Сначала идет старый сервер, потом новый

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

Ждёте окончания синхронизации. Она должна быть не долгой, так как перед остановкой почтового сервера вы и так накатили все изменения. Обычно несколько минут занимает процесс финального копирования. Когда он закончен, выключаете старый сервер, убираете его из автозагрузки гипервизора. На новом сервере меняете IP на адреса старого сервера и перезагружаете его. Можно и не перезагружать, но я для проверки всегда перезагружаю. Можно не менять IP адрес, если у вас все завязано на dns имена, отредактируйте dns запись. Но я обычно все же меняю ip, так надежнее. Обязательно найдется какое-нибудь старое оборудование, типа сканера, где адрес указан в виде ip адреса и т.д. Эти лишние проблемы потом не нужны. Лучше все сделать максимально незаметно и надежно.

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

Бывает, что не все идет гладко. У меня были ситуации, когда после перехода уже на новый сервер, начинались проблемы, которые предусмотреть заранее было нельзя. Новое хранилище начинало тормозить или возникали еще какие-то проблемы. Например, с блокировками на nfs. Вы это не проверили заранее. С работой dovecot на nfs есть свои нюансы. Если вы понимаете, что оставить в работе новый сервер нельзя и надо откатываться, то нужно опять синхронизировать почтовую базу, если для вас важна та корреспонденция, которая была доставлена в то время, как поработал новый сервер. Для этого останавливаете почтовые службы на новом сервере, меняете на нем ip, запускаете старый и выполняете синхронизацию в обратном порядке — с нового на старый. Не ошибитесь в параметрах rsync! После этого оставляете старый сервер в работе, а с новым спокойно разбираетесь и готовите его еще раз к переносу.

Вот, в принципе, и все по переносу почтового сервера из моей практики. Я их переносил штук 10 за все время админства. Можно сказать руку набил.

Перенос данных один-в-один

Название говорит само за себя — не получится в процессе данного переноса обновить операционную систему или распределить сайты по разным пользователям. Это перенос данных сервера один-в-один — взяли данные и в том виде, как они есть, перенесли на новый сервер. Поэтому вероятность того, что что-то не заработает, минимальна.

Когда использовать

Идеально подходит для случаев, когда у вас на сервере выставлены нестандартные настройки, и вы хотите сохранить всё, как есть.

Может быть выполнен путем:

Физического перемещения жёсткого диска сервера или образа диска VDS.
Программно, то есть копированием всех данных.

Перемещение жесткого диска для выделенного сервера или образа диска для виртуального

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

Что нужно знать:

Размер дисков на выделенных серверах не влияет на скорость переноса.
Нельзя уменьшить диск, если это VDS; нельзя уменьшить/увеличить диск на выделенном сервере.
Программное обеспечение может не заработать на новом «железе». Например, Centos 6 не заработает на Scalable, Windows с высокой вероятностью не заработает после такого переноса вообще, если тип железа поменялся.

Программный перенос

Под программным переносом понимается копирование со старого сервера на новый всех файлов (кроме директорий /dev, /sys и /proc) от корня.

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

Обязательное требование — доступ по ssh под суперпользователем на оба сервера.

Во время копирования исходный сервер остаётся доступен.

Что нужно знать:

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

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

Какой диск выбрать в kvm — lvm, raw (img) или qcow2

В kvm есть несколько типов дисков, которые вы можете использовать в своей работе. Они имеют принципиальные отличия как по своей работе, так и по способам бэкапа. Выбирать тот или иной тип нужно в зависимости от ваших задач. Рассмотрим эти типы подробнее.

LVM. Тут все понятно. Использование lvm томов в виде дисков виртуальных машин. Такой диск будет блочным устройством и должен работать быстрее всех остальных типов, так как нет лишней прослойки в виде файловой системы.

Плюсы:

Снэпшоты средствами самого lvm, с них легко снять бэкап без остановки виртуальной машины.
Максимальное быстродействие.
Легко изменить размер диска.

Минусы:

Более сложное управление по сравнению с дисками в виде отдельных файлов.
Менее гибкое управление пространством диска. Если весь диск разбить на lvm разделы для виртуалок, то места на нем не останется, даже если вируталки будут пустые.
Более сложный перенос на другой сервер.

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

Плюсы:

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

Минусы:

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

QCOW2. Родной формат для гипервизора QEMU. Расшифровывается как QEMU Copy-on-write. Этот формат позволяет создавать динамические диски для виртуальных машин, а так же поддерживает снепшоты. Теоретически, скорость работы должна хоть и не сильно, но уступать RAW. Как обстоит дело на практике, я не знаю, не замерял и подробно эту информацию не проверял.

Плюсы:

Поддержка снепшотов и динамических дисков. Как следствие — более удобное управление дисковым пространством.
Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.

Минусы:

Более низкая производительность, по сравнению с другими типами образов.

У каждого типа есть свои преимущества и недостатки. Lvm проще всего бэкапить, но им сложнее всего управлять. Для того, кто хорошо знаком с lvm это не проблема, если сталкиваешься первый раз, то возникает много вопросов. У raw нет снепшотов, лично для меня это большой минус, я этот формат вообще не рассматриваю. Если нет максимальной нагрузки на дисковую подсистему, то QCOW2 мне кажется наиболее приемлемым вариантом. Собственно, ниже и пойдет рассказ, как совместить удобство управления QCOW2 и простоту бэкапов и снэпшотов lvm. Я покажу, как сделать живой бэкап виртуальной машины kvm в формате qcow2 без остановки виртуальной машины.

Заключение

Для того, чтобы любые работы на prod сервере прошли успешно, я всегда соблюдаю несколько правил:

Никогда не тороплюсь. Если реально нет необходимости спешить, я всегда довожу до руководства, что спешка не нужна. Она вредит и мешает все сделать хорошо. Пусть лучше я спокойно неделю или две подготовлюсь, все обдумаю, проверю и перенесу без проблем, нежели я буду спешить для соблюдения бессмысленных сроков.
Тщательно все проверяю и перепроверяю. Делаю все максимально незаметно. Если простой ожидается маленький, не шлю никому никаких уведомлений. Если вы предупредите, что будут работы с почтовым сервером, на следующие дни обязательно кто-то нажалуется, что после переноса все сломалось. Это мешает снимать реальные обратные связи. Когда никто не знает о переносе, отзывы будут только на реальные проблемы, а не надуманные.
У меня всегда есть запасной план на случай, если что-то пойдет не так. Всегда под рукой актуальные бэкапы и подменные системы. Я точно знаю, что буду делать, если новый сервер не будет введен в эксплуатацию.

Этого достаточно, чтобы успешно проводить любые работы на серверах. Главное, все запланировать заранее, чтобы не было спешки. А как вы планируете масштабные обновления или переносы prod серверов?

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

Познакомитесь с Terraform.
Изучите систему управления конфигурацией Ansible.
Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .

Заключение

Я постарался рассказать подробно и понятно о полной настройке ELK Stack. Информацию в основном почерпнул в официальной документации. Мне не попалось более ли менее подробных статей ни в рунете, ни в буржунете, хотя искал я основательно. Вроде бы такой популярный и эффективный инструмент, но статей больше чем просто дефолтная установка я почти не видел. Буквально одна на хабре попалась с какой-то более ли менее кастомизацией.

Какие-то проверенные моменты я не стал описывать в статье, так как посчитал их неудобными и не стал использовать сам. Например, если отказаться от logstash и отправлять данные с beats напрямую в elasticsearch, то на первый взгляд все становится проще. Штатные модули beats сами парсят вывод, устанавливают готовые визуализации и дашборды в Kibana. Вам остается только зайти и любоваться красотой Но на деле все выходит не так красиво, как хотелось бы. Кастомизация конфигурации усложняется. Изменение полей в логах приводит к более сложным настройкам по вводу этих изменений в систему. Все настройки поступающей информации переносятся на каждый beats, изменяются в конфигах отдельных агентов. Это неудобно.

В то же время, при использовании logstash, вы просто отправляете данные со всех beats на него и уже в одном месте всем управляете, распределяете индексы, меняете поля и т.д. Все настройки перемещаются в одно место. Это более удобный подход. Плюс, при большой нагрузке вы можете вынести logstash на отдельную машину.

Я не рассмотрел в своей статье такие моменты как создание визуализаций и дашбордов в Кибана, так как материал уже и так получился объемный. Я устал писать эту статью Смотрите остальные мои материалы по данной теме. Там есть примеры.

Так же я не рассмотрел такой момент. Logstash может принимать данные напрямую через syslog. Вы можете, к примеру, в nginx настроить отправку логов в syslog, минуя файлы и beats. Это может быть более удобно, чем описанная мной схема. Особенно это актуально для сбора логов с различных сетевых устройств, на которые невозможно поставить агента, например mikrotik. Syslog поток так же можно парсить на ходу с помощью grok. Отдельно надо рассмотреть автоочистку старых индексов в elasticsearch.

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

Все статьи раздела elk stack — https://serveradmin.ru/category/elk-stack/.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .