だから、もしあれば、 yagodkinvsが持っていたように :
バックアップはWebフェイスのサーバーでしたが、電話を使用するのはそれほど簡単ではありません...
それから猫にようこそ。
![](https://habrastorage.org/files/c27/3d1/013/c273d1013343437296c5cb883f5118f7.jpg)
1つのプロジェクトに参加し、電話の初期設定とさらなるメンテナンスを担当しました。 プロジェクトは時間とともに成長し、要件は変化しました。その1つは、電力の損失やプロバイダーでの主な事故(インターネットおよび/または電話)の例外を除いて、コールセンターの中断のない運用でした。
これはどのように解決されましたか?
電話番号が1つある場合、電話番号を100%予約することは不可能です。 通信事業者との事故の場合、あなたは何もすることができません。
したがって、彼らは次のように行動した。 メインのテレフォニーサーバーは、大まかに言えば、オフィスからクラウドに持ち出されました。 その予約のために、安価なホスティングの2番目が発生しました。
バックアップの設定-マイナーなニュアンスを除くメインのコピー。
プロジェクトマネージャーには、サーバー間でテレフォニーを自動的に切り替えるための次のオプションが提供されました。
- 特にDNSを使用してください-Amazonから。 そこで、フェイルオーバーやその他のパラメーターを使用して、2つのサーバーのIPアドレス間のvoip.company.proなどの非常に高速な名前切り替えを構成できます。
- バランサーを使用します。 KamailioとAsteriskの設定オプションは、それだけでなく、ネットワークのオープンスペースにあります。
第1の実施形態では、SIPクライアントは、登録タイムアウトが働いた後に新しいサーバーに切り替わることに留意されたい。
2番目のケースでは、認証はアスタリスクの外でバランサー自体に移動しました。
しかし、DNSでオプションを破った顧客はこれを拒否しました。 エンドデバイスのDNSサーバーの情報を更新するのは非常に時間がかかることを正当化します。
2番目の選択肢は延期されました。これは、これまであまり多くのオペレーターが存在せず、顧客がこのスキームをまだ複雑にしたくないためです。 まあ、バランサーは2番目のオプションの弱点であり、予約する必要があります。
顧客は、別のオプションを検討することを提案しました-SIPクライアントのオペレーターに2つのアカウントを設定します。 これらは本質的に同一であり、唯一の違いは接続サーバーにあります。 そして、私にとっては、サーバー間のテレフォニーの切り替えを解決する必要があります。
つまり、加入者側のスキームの一部は次の形式を取りました。
![](https://habrastorage.org/files/1b9/596/c0b/1b9596c0b7684e22a455abae5193c626.png)
完全ではありませんが、顧客はそのような決定を主張し、SIPクライアントのセットアップに関わるすべての労力は彼が引き受けました。 既存のシステム管理者に割り当てられます:)
次。 とにかく電話が届くように、別のサービスプロバイダーから追加の固定電話番号をレンタルしました。
番号は、メインの番号とともにサイトに投稿されます。
両方の電話サービスプロバイダーの個人アカウントでは、両方のサーバーがSIPクライアントとして接続されていました。
着信コールを処理するためのスクリプトは、次のスキームに従って構成されました。
- 着信コールが到着すると、メインサーバに送信され、ダイヤルアップ時間は20秒でした。
- メインサーバーが利用できない場合、コールはバックアップに送信され、ダイヤル時間は20秒です。
- バックアップサーバーが利用できない場合、コールはボイスメールに送信されました。
ほとんどすべてのVOIPプロバイダーでは、個人アカウントで、またはサポートサービスへの要求に応じて、このスキームを構成できます。 少なくとも当社が選択したものについては、お客様の個人アカウントで設定します。
次のスキームが判明しました。
![](https://habrastorage.org/files/ce8/157/0f5/ce81570f58a44c2281a02d5b391419ad.png)
サーバーはSIPクライアントに対して外部にあるため、顧客は特別な問題なしにコールセンターのインターネットアクセスチャネルを予約できます。 私は言わなければならないが、彼はさらに進んで、コールセンターを予約し、別の都市でその一部を開いた。
結論
実装されたスキームにより、次のような場合にコールセンターのダウンタイムを回避できました。
- 何らかの理由で、テレフォニーサーバーの1つの障害。
- コールセンターの1つでの電気および/またはすべてのインターネット通信チャネルの損失
- 通信サービスプロバイダーの1つとの事故
もちろん、これらのいずれの場合でも、現在の呼び出しは切断され、後続の呼び出しはバックアップスキームに従って既に到着しました。
夕方、監視中にバックアップ回路に切り替えるケースを見たときの満足感を覚えています。
そして、誰もパニックの叫び声で私を呼んではいませんでしたが、これは実際には気づかれていませんでした。
ご清聴ありがとうございました! 誰もがこの資料が役立つことを願っています。