Падение телефонии даже на десять минут — критическая ситуация для некоторых учреждений, например, скорой или МЧС. Как сделать IP-телефонию отказоустойчивой, рассказывает Лев Рыбников, VOIP инженер-эксперт компании «Авантелеком».
Отказоустойчивые решения создаются за счет дублирования как аппаратных, так и программных компонентов АТС. Например, установки двух серверов или баз данных.
В случае с телефонией, развернутой на собственном оборудовании, необходимо дублировать не только серверы, но и электропитание, коммутаторы локальной сети, маршрутизаторы и Session Border Controller (SBC), если он присутствует. Схемы 1+1 достаточно в 99% случаев.
Для повышения надежности важно уделить внимание электропитанию. Нужно использовать надежные источники бесперебойного питания, а, если есть бюджет, — оборудование с двумя блоками питания.
При этом необходимо организовать инфраструктуру так, чтобы при падении основной АТС резервная копия запускалась автоматически. Это достигается за счет кластерной архитектуры, ее можно реализовать тремя способами.
🔹 Кластер на аппаратном уровне с использованием гипервизоров. При сбое виртуальная машина с АТС автоматически запускается на другом физическом сервере средствами самого гипервизора.
🔹 Кластер на программном уровне, когда кластеризуются все ресурсы АТС. Резервная АТС всегда находится в горячем режиме и, при крахе основной, берет на себя ее функции. Когда мы испытывали такую схему у себя, резервная АТС запускалась через 3 секунды после падения основной.
🔹 Резервная АТС в облаке вендора. В этом случае после падения основной телефонии клиент запускает копию, размещенную в облаке провайдера. Этот вариант подходит учреждениям, которым неудобно создавать копию на собственном оборудовании.
Если же в организации пользуются облачной телефонией, то точка отказа — подключение к интернету. Нужны два провайдеров, которые заходят в здание по разной инфраструктуре. Часто провайдеры работают на общей инфраструктуре, например, по одному кабелю, входящему в здание, — такой вариант не подходит.
В случае с телефонией, развернутой на собственном оборудовании, необходимо дублировать не только серверы, но и электропитание, коммутаторы локальной сети, маршрутизаторы и Session Border Controller (SBC), если он присутствует. Схемы 1+1 достаточно в 99% случаев.
Для повышения надежности важно уделить внимание электропитанию. Нужно использовать надежные источники бесперебойного питания, а, если есть бюджет, — оборудование с двумя блоками питания.
При этом необходимо организовать инфраструктуру так, чтобы при падении основной АТС резервная копия запускалась автоматически. Это достигается за счет кластерной архитектуры, ее можно реализовать тремя способами.
🔹 Кластер на аппаратном уровне с использованием гипервизоров. При сбое виртуальная машина с АТС автоматически запускается на другом физическом сервере средствами самого гипервизора.
🔹 Кластер на программном уровне, когда кластеризуются все ресурсы АТС. Резервная АТС всегда находится в горячем режиме и, при крахе основной, берет на себя ее функции. Когда мы испытывали такую схему у себя, резервная АТС запускалась через 3 секунды после падения основной.
🔹 Резервная АТС в облаке вендора. В этом случае после падения основной телефонии клиент запускает копию, размещенную в облаке провайдера. Этот вариант подходит учреждениям, которым неудобно создавать копию на собственном оборудовании.
Если же в организации пользуются облачной телефонией, то точка отказа — подключение к интернету. Нужны два провайдеров, которые заходят в здание по разной инфраструктуре. Часто провайдеры работают на общей инфраструктуре, например, по одному кабелю, входящему в здание, — такой вариант не подходит.
Вам может быть интересно:
Зачем нужна функция настройки IP-телефонов AutoProvision
На настройку одного IP-телефона уходит 5-10 минут. Но что делать, если в компании несколько сотен или тысяч абонентов?
На настройку одного IP-телефона уходит 5-10 минут. Но что делать, если в компании несколько сотен или тысяч абонентов?
Как с помощью Mikrotik можно защитить телефонию от DDoS и других атак
Вне зависимости от выбранной системы, существует риск стать жертвой атаки, в результате понести денежные убытки, утратить информацию или потерять сервис.
Вне зависимости от выбранной системы, существует риск стать жертвой атаки, в результате понести денежные убытки, утратить информацию или потерять сервис.
Будьте в курсе главных новостей и аналитики отрасли:
Читайте нас в Telegram: «А вам телеком?»
