おそらく、2011年にPBX-SphereプロジェクトがSMB用のサーバーベースの専用ソフトウェアとして計画されたという事実から始める価値があります。これは、シンプルでわかりやすいソフトウェア製品で複雑なVoIPテクノロジーを実装および維持する問題を解決することになっています。 そのため、2011年7月1日に、PBX-Sphere Enterprise 1.0の最初の安定リリースがリリースされました。 その後、世界中に多くのベータテスターといくつかの大規模な顧客を獲得しました。 2013年10月15日まで、最新の2.2.0を含む3つのより安定したバージョンのPBX-Sphere Enterpriseをリリースしました。 また、6か月以内に、当社の製品を大規模な顧客に積極的に宣伝しました。 その結果、2014年半ばの時点で、アクティブエンドユーザーは1000人未満でした。 これは失敗だと言っているわけではありませんが、より良い結果が期待されていました。
そして、数年にわたって変化した市場を分析した結果、「サービスとしてのソフトウェア」（SaaS）モデル、クラウドテクノロジーに移行する必要があることに気付きました。 数か月で、新しい製品コンセプトを開発し、PBX-SphereエンタープライズをPBX-Sphereオンラインにリファクタリングし始めました。
最初の質問は、システム展開プラットフォームの選択でした。 いくつかの調査と実験の後、私たちは3つから選択することにしました：Hetzner Dedicated Servers、Microsoft Azure、私たち自身のサーバーのクラスター。
私はより詳しく教えます：
Hetzner専用サーバー
Intel Core i7、48 GB RAM、RAID1の2 x 2 Tb HDDおよびFlexiPackを備えた物理サーバー-保証帯域幅200 Mbpsで月額75ユーロ。 あなたはこれ以上何を望みますか？！ 展開を開始しました。 最初は、すべてが素晴らしかった。 さまざまなPBX-Sphere Online展開展開の役割のために、多数のCentOS 7サーバーを展開しました。 負荷テストは優れた結果を示しました。 この状況に励まされて、私たちはこの構成でPBX-Sphere Online 1.0をオープンし、1つの大規模なクライアントの産業用に使用しました。 すべてが完璧に機能しました。 会話中に音の短期的な「フェード」が発生する可能性があるという苦情がいくつかありました。 これは、ユーザーのインターネット接続の不安定性に起因します。これは、一部のチャネルで損失が検出されず、サーバーの負荷平均と使用済みRAMおよびスワップのサイズが最小だったためです。 しかし、すぐに、使用されているコーデックに関係なく、3Gネットワークでインターネットを使用する場合、1分あたり数回、音声の短期的な「フェード」がほとんど常に観察されることに気付き始めました。 私たちは、問題が何であるかを把握することにしました。なぜなら、私たちのオフィスにあるテストサーバーを使用するとき、このような問題は決して発生しなかったからです。 Hetznerボーダー機器が誤ってシェーピングを使用していることを発見したときの驚きを想像してください。その結果、RTPパケットはサーバーへの配信のためにキューに入れられ、RTPのTTLパケットよりも高い遅延で戻ります。 ユーザーに適切なインターネットチャネルがあり、TCP交換プロトコルが選択されている場合、問題はありません。 ヘッツナーのサポートとの1週間の交渉では結果は得られませんでした。 もっともっと。 3日以内に、5台のハードドライブがサーバーで故障しました！ さらに、そのうちの2つは中央のSQLサーバー上にあります。 幸いなことに、SQLサーバーが重複していたため、ユーザーには気付かれませんでした。 「WTF？」と尋ねられたとき、ヘッツナーのサポートは、これは正常であり、順番どおりであると答えました。 さらに2台のハードドライブが死に、ネットワークの問題が続いた後、別のプラットフォームを探す必要があることが明らかになりました。
Microsoft Azure
Microsoft Azureの第一印象は、クール、珍しい、高価な3つの言葉で説明できます。 これらは、通常の意味での仮想マシンだけでなく、独自の法律と微妙さを備えた完全に独立した環境です。 試してみることにしました。 PBX-Sphere Onlineを展開し、テストモードで実行しました。 私たちは長い間よく調べ、すべてのシステムの両方の負荷テストを行い、実際の条件でテストしました。 彼らはヘッツナーで出会った問題が現れるのを待っていました。 これは起こらず、「フェージング」音はありませんでした。 しかし、IPアドレスの潜在的な問題はすぐに明らかになりました。 ご存じのとおり、Azureには、インスタンスのローカルIPアドレスと2つの外部IPアドレス（VIPおよびPIP）の3種類のIPアドレスがあります。 VIPアドレスの操作は、ホームルーターの操作に似ています。外部IPアドレスがWANインターフェイスに到着し、世界から内部ネットワークに到達するためには、特定のポートを転送する必要があります。 AzureのVIPと同じメカニズム。 これは、バックエンドサーバーを除くすべてのPBX-Sphereオンライン展開で受け入れられます。バックエンドサーバーでは、通話中の直接音声（RTP）に全範囲のポートが必要です。 Azureでは、インスタンスごとに最大150ポートを転送できます。 したがって、RTPの場合、別のタイプの外部IPアドレスであるPIPを使用する必要があります。PIPは、すべてのポートがインスタンスにあります。 動作します。 ただし、VIPおよびPIPアドレスはデフォルトで動的です。 つまり、VIP / PIPサーバーを再起動すると、アドレスが変更される場合があります。 また、VIPアドレスをDNSで簡単に特定できる場合、PIPアドレスは、外部要求を実行することによってサーバーの内部からのみ判断できます。 次に、ドメインゾーンを構成する方法は？！ ユーザーの最終機器を認証するには、インスタンスホストのエイリアス（CNAME）であるドメイン名を使用できます。 ただし、DNSのAzure PIPアドレスは提供しません。 したがって、同じインスタンスがVIPアドレスを使用してユーザーを認証し、音声（RTP）がPIPアドレスを介してルーティングされます。 このような実装の場合、各再起動後、各バックエンドインスタンスは外部からPIPアドレスを要求し、その後RTPの再構成を実行する必要があります。 さいわい、RTPの場合、DNSに個別のエントリは必要ありません。 一般的に、そのようなメカニズムはひどく不便です。 サーバーは、IPアドレスを報告する外部リソースに直接依存します。 インスタンスにPIPアドレスを割り当てる方法が見つかりませんでした。 もう1つの不快な瞬間は、Microsoftがデータセンターでメンテナンスを実行し、その結果、一部のサーバーが使用できなくなることです。 さまざまな地域のコンピューティングリソースの過剰な冗長性を節約するため、このようなアクションはユーザーに透過的であり、品質を損なうことはありません。 しかし、これは直接費用を犠牲にして達成されます。なぜなら、私たちは自分の費用でそのような予約を提供しなければならないからです。 他のすべての点で、サービスの品質は単純に優れていますが、すでに述べたように、非常に高価です。
独自のクラスター
このオプションは理論的にのみ計算されました。 実際、PBX-Sphereチームのほとんどはウクライナにあり、残りはロシアとブルガリアにあります。 PBX-Sphereは、CIS諸国だけでなく、ほとんどの場合、米国とEU諸国にも焦点を当てています。 したがって、ご存じのように、ロシア、ウクライナ、ブルガリアのいずれもサーバーのホスティングには適していません。 また、通貨リスクのヘッジの可能性を考慮しても、他の国にサーバーを展開し、技術専門家の頻繁なフライトでサポートを提供することは非常に高価です。 おそらく将来、このオプションを検討するために戻ってくるでしょう。
マイクロソフトのサポートのおかげで、私たちはBizSparkプログラムの参加者になりました。このプログラムは、とりわけ、2年間、月額750ドルでAzureサービスを無料で提供します。 このサポートと、Azureエンジニアとの直接の連絡のおかげで、PBX-Sphereオンラインにこのプラットフォームを選択しました。 そして、今のところ、これに非常に満足しています。
まとめ
2015年8月27日に、Microsoft AzureプラットフォームのPBX-Sphere Onlineをすべてのユーザー向けにバージョン2.0.0にアップグレードし、最初に公開登録を開始しました。 現在、新しいアカウントにはそれぞれ25の無料ライセンスが提供されています。
PBX-Sphereオンライン-どうやってやったか
All Articles