物理クラウドホストサーバは専用物理UCloudは、優れたコンピューティング性能を備えている、コアシナリオは、高いパフォーマンスと安定性の要求を満たすため、および他の製品との柔軟であってもよいです。物理クラウドゲートウェイは、複数のユーザーを展開する必要性に起因する各製品の物理的およびパブリッククラウドとの間の内部ネットワーク通信、クラスタ間のクロス地域流れ圧力に対向ゲートウェイクラスタを運ぶために使用されます。
我々は、マルチ、トンネルトラフィックと象の流れ容量管理と検疫によって過負荷に起因するトラフィックのハッシュ偏光、及び可逆移動の制限を解決するための他の手段を破ります。起動プログラムので、クラスタがキャリアからアップグレードされた二から一一を通じてスムーズに他のユーザの人々のトラフィックのピークを支援するために、数百G Gの流れを運ぶことができます。以下は、共有への実践的な経験です。A
トラフィックの過負荷雲物理学
高可用性クラウドサービスを確保するためには、ユーザーは通常、異なる事業分野に展開します。この時点で、クラウド・ユーザーは、物理クラウド・ゲートウェイを介して相互に物理的にアクセスする必要があり、必然的に、物理的なクラウド・ゲートウェイは、クラウド・クラスタ・トラフィックを横切る物理ホストの多数を運ぶであろう。
一方、部屋の異なるユーザ間の任意の内部の単離および訪問ネットワークトラフィックを確実にするために、ユーザは、物理的にクラウドゲートウェイトンネルがパケットをカプセル化し、受信者に送信します。
1、問題：ハッシュ偏光雲と物理的な過負荷
以下に、我々はクラスタサービス2へのすべてのアクセスに影響を与え、物理的なクラウドクラスター2電子ゲートウェイデバイスの帯域幅の過負荷ことがわかります。トラヒック分布が一様なクラスター2ない監視することによって確認するには、クラスタ帯域幅は、デバイスのフック部から外れているが、デバイスの残りの部分は非常に小さい流量です。パケット・キャプチャによって、トラフィックゲートウェイ装置Eは、物理クラスタ1からほぼ完全に雲。
図：場合の模式断面クラスタアクセストンネルカプセル化
：ビジネス分析をバインドする物理的なクラウドの過負荷という原因を特定するための物理的なトラフィックの訪問の間には、不均一な流れ分布が得られ、クラスタ1とクラスタ2ハッシュ偏光表示され曇らせます。
だから、ハッシュ分極それは何ですか？
本だけ外例えば等IP、MAC、トンネルカプセル化の皮との間の単一のクラスタ伝送トンネルユーザの元の情報の使用は、トンネル情報、及びSIPとDIPを使用して一意のトンネル。その後、トラフィックが得られ、計算結果と一致し、同じハッシュアルゴリズムは、非常に優れた負荷分散を行うことができない、クラスタの単一のデバイス急激な負荷になります、現象が、それによってクラスタに影響を与え、極端な場合にオフフックように見えますすべてのユーザー、これはデバイス間で複数のシーンでは、多くの場合、ハッシュが表示され、偏光ハッシュです。
現状によると、我々は2つの観点から問題を解決しようとしています。
①ユーザトラフィックは、ハッシュ分極カプセル化トンネルを回避する方法、分割することができますか？
②ユーザトラフィックがフック物理クラウドネットワークオフ「象の流れ」を防止する方法、別れることができない場合は？
今、我々は解決策を対応する二つの研究から始めています。
2、どのようにカプセル化されたトンネルハッシュ偏光を避けるために？
この問題に対処するために、我々は最初にいくつかのソリューションを提案しています：
① プログラム1：ユーザトラフィックは、クラスタポーリング各デバイスにスイッチから送信されます。この方法の利点は、流れが完全に解体することができ、それはハッシュ偏光を表示されないことです。しかし、欠点は、タイミングがビジネスユーザーに影響を与える可能性があるネットワークパケットを中断していることです。
②シナリオ2：スイッチベースのトンネルの内部パケットのハッシュ。この方法は、異なるデバイス上でよりバランスの取れたクラスタを分割することができるという利点は、壊れたユーザパケットに基づいています。問題は、ユーザの意志トンネルカプセル化されたパケットの断片化は再び、インナーリード及びメッセージ情報削除ハッシュが異なるデバイスにパケットを断片化することです。
③スキーム3：各装置のクラスタは別個のトンネル送信元IPを割り当てられます。この方法は、分割効率的なトラフィックを実現することができますが、原因のトンネルの限られた数に、既存のネットワーク内で不均一なパフォーマンスのハッシュ問題は依然明らかです。
これらの三つの方法は、程度の差欠点を持って、完全に分極ハッシュの問題を解決しません。研究のシリーズを通じて、我々は最終的に見つけ、マルチトンネルソリューションを。ユーザの内部メッセージ情報のハッシュに基づいて、トンネルのネットワークIPを結合するために、ゲートウェイの全てを単一のトンネル・ゲートウェイ・モードを壊し、その異なる流れを確実にするためにできるだけトンネルセグメントSIPとDIPに予め割り当てを選択することユーザトラフィックを破るだろう異なるトンネルに分布します。
図：マルチトンネルソリューション概略
3、どのようにフック物理クラウドネットワークオフ「象の流れ」を防ぐには？
前提マルチトンネルオプションは、ユーザトラフィックを分割することができるということであるが、あなたは「象のストリームを」発生した場合の平均？さらにトンネルは避けるためにオフフックにすることはできません。ユーザーの「象の流れ」の顔は、技術だけでは十分ではありません、我々はまた、必要なハードウェア構成から予防と回避を進めることができません。
■スタンドアローン容量管理
最初必要妥当物理容量管理クラウドゲートウェイ、ミートユーザニーズにクラスタ全体の伝送容量を確保しつつ、ユーザは、物理ホスト雲の帯域幅より大きい帯域幅を運ぶことができるようにするゲートウェイ。
図：例 - 10Gから25Gに単位容量を調整します
这一点其实与云厂商自身的能力密切相关，目前UCloud网关集群单机的承受能力远远大于单个用户的流量，在承载多用户汇聚流量的情况下，仍能保证个别用户的突发“大象流”不会打爆网关。
■ 隔离区无损迁移
提升单机容量还远远不够，以防万一，UCloud还配备了隔离区，隔离区通常是无流量通过的。
图：隔离区无损迁移
如上图，一旦监测到流量过大，存在集群被打爆的风险时，集群配套的自动迁移系统便会修改需要迁移的物理机数据库信息，并自动更新对应转发规则，部分业务流量便可通过隔离区分担出去。同时我们还会基于强校验技术对迁移结果进行自动验证，保证迁移业务的无损可靠。
4、实例：新旧方案下的用户应用对比
在新方案上线前，由于Hash极化现象，集群通常只能承载几十G的流量，并且不时出现过载的状态。
新方案上线后，如下监控图，可以看到流量基本在集群上打散，集群的优势得到了充分发挥，目前集群可以承载上百G的流量，充分抵御用户业务量突增时的风险。例如达达在双十一时60G的流量压力是普遍现象，突发时还会出现流量达到100G的情况，此时集群流量依旧转发正常，对业务毫无影响。
图：流量监控图示意
除了提升性能，这次集群升级中对高可用设计也做了优化。
二、集群升级后的高可用性优化
针对集群升级，一般情况下会先部署新灰度集群，然后将用户业务逐步进行迁移。这样的好处在于可以在新集群版本存在缺陷的情况下，最大限度的控制影响范围，当出现故障时，可以及时回迁受影响的用户业务到老集群，避免用户业务受到影响。
图：预期结果-新Manager接管灰度集群
在灰度过程中，曾发现一个问题。
在新集群Manager部署完毕后，由于配置错误导致灰度集群接管了旧集群，Manager基于配置文件的集群信息自动接管集群的控制，并直接下发配置信息，旧集群接受错误配置。由于旧集群和新集群配置差异较大，导致旧集群在解释新配置时有误，出现高可用异常。
图：灰度Manager错误接管旧集群示意
1、风险分析
为了系统性避免这类问题，我们对配置过程进行了回溯分析，总结了存在的风险：
① 部署人为干预多，会加大故障概率；
② 程序的异常保护不够；
③ 集群之间的有效隔离不足，若故障影响范围大。
2、优化：自动化运维&程序优化&隔离影响
■ 自动化运维
自动运维化通过自动化代替人工操作，可以有效避免人为错误的发生。我们对集群部署流程进行了优化，将其分为配置入库和部署两个流程，运维人员只需录入必要的配置信息，其余均通过自动化生成部署。
■ 完善校验和告警
此外，我们还对部分程序作了优化，加大对异常配置的校验。例如，配置加载前，首先需进行白名单过滤，如果发现配置异常则终止配置加载，并进行告警通知后续人工介入。
图：白名单限制程序，只允许正确的控制面同步配置
■ 隔离影响
最后，不管自动化运维机制和程序自身多精密，总要假设异常的可能。在此前提下，还需要考虑在故障发生时如何最大程度地减少影响范围和影响时间。我们的解决思路如下：
► 去除公共依赖
両側のために損失をもたらす、異常なマネージャーに依存しながら、すべてのクラスタに起因する従来の装置の主な問題。影響を低減、デバイスがパブリックに依存しているクラスターを除去する必要があります。効果範囲を制御することができます異なる結合マネージャの例えば異なるクラスタ、。もちろん、だけではなく、国民がクラスタに依存しているがマネージャに表示されること、またはそれは我々が実際のプロジェクトの慎重な審査を必要とするIP、ラック、などであってもよいです。
► 設定検疫制御された状況下では、影響範囲、マネージャが異常最もため、例外も迅速にデバイスを削除したり、直接分離領域にクラスタ内のすべてのユーザーを移行すべき場合には、クラスタ内のデバイスの一部のみに影響します速い時のトラブルシューティングを行います。
概要
技術・事業開発、ますます複雑なシステムアーキテクチャの拡大に伴い、ますます密接な相関関係は、技術者の需要も増加しています。物理的なクラウドゲートウェイクラスターの開発中に、あなたは必然的に「ピット」の多くが発生しますが、あなたはポイントを維持するために必要とされるたびに：すべての技術は、ビジネス・サービスのためのものです。この目的のために、我々はあなたに多くの思考と収穫を与えることを期待して、設計アウトで共有体験を計画しています。
