8

私は DC/OS オーケストレーターを使用して ACS を少し試しています。1 つのリージョン内でクラスターをスピンアップするのは簡単に思えますが、複数のリージョンにまたがるデプロイを行うためのベスト プラクティスがどのようなものかはよくわかりません。

現在、Azure 自体は、複数のリージョンへの展開をサポートしていないようです。その前提で、他の唯一の選択肢は、利用可能にしたいすべてのリージョンで複数の同一のクラスターを作成し、Azure Traffic Manager を使用して受信トラフィックを最も近い利用可能なクラスターにルーティングすることだと思います。

このソリューションは機能しますが、回避方法について 100% 確信が持てないいくつかの問題も引き起こします。

  1. 新しいバージョンのサービスをデプロイする場合、デプロイ パイプラインはすべてのリージョンに確実にデプロイする必要があります。米国東部と北ヨーロッパのリージョンがある場合、CI ツールからのデプロイ中に、両方のリージョンで Marathon API に接続して新しいデプロイをトリガーする必要があります。デプロイが 1 つのリージョンで失敗し、別のリージョンで成功した場合、2 つのリージョン間に突然格差が生じます。
  2. PostgreSQL や ElasticSearch などのローカル永続ボリュームを使用するサービスをデプロイしている場合、サービス ディスカバリーはリージョンに対してローカルなサービスのみを検出するため、両方のリージョンにインスタンスが必要です。これにより、すべてのリージョンですべての状態を維持するために、リージョン間のレプリケーションの問題が発生します。これを機能させるには、いくつか/多くの手動構成が必要なようです。

Azure Container Service (または実際には Amazon Container Service、同じ課題が見つかると思います) を使用してこのようなセットアップを使用したことがあり、これにアプローチする方法についていくつかの指針がありますか?

4

2 に答える 2

0

おっしゃる通り、ACS は現在マルチリージョン展開をサポートしていません。

あなたの最初の問題は DC/OS の Marathon に固有のものです。エンジニアの何人かに連絡して、ベスト プラクティスに関する情報があるかどうかを確認します。

2 番目のポイントは、私たち (私は ACS PM) が検討しているものです。特定のシナリオで使用できるソリューションがいくつかあります (たとえば、ArangoDB は DC/OS ユニバースにあり、レプリケーションを提供します)。DC/OS チームは、ここでも何か言いたいことがあるかもしれません。ACS では、このユース ケースのソリューションを提供するための最善のアプローチを評価していますが、タイムラインを示すことはできません。

代替ソリューションは、データベースを SaaS オファリングに含めることです。これにより、冗長性とレプリケーションの管理の複雑さがすべて解消されます。

于 2017-01-10T00:43:58.337 に答える