サーバーのエニーキャストを取得するにはどうすればよいですか？
私は自分のWebサービスのエニーキャストを取得したいのですが、これを実現する方法や支援できる会社に関する情報が見つかりません。
エニーキャストDNSを提供する多くの企業を見つけましたが、それは私が必要としていることではありません。
エニーキャストを使用して負荷を分散し、稼働時間を増やすために、地理的に分散したいステートレスWebサービスがあります。企業が複数のデータセンターでIPアドレスをアドバタイズできないだけの技術的な理由はありますか？
エニーキャスティングについて、既存のオファリングを評価し、私に役立つ可能性のある企業を見つけるために知っておく必要がある技術的側面は何ですか？注意すべき落とし穴は何ですか？
特定のリクエストに対応するために理解する必要があるエニーキャストについては、2つの異なる側面があります。最初の部分は、エニーキャストアドレスがアドバタイズされてルーティングされる方法です。 2つ目は、エニーキャストアドレスに対するTCPの課題と、その対処方法です。
アナウンスとルーティング
BGPテーブルを許容可能なサイズに保つために、ほとんどのASは、プレフィックスが長すぎる場合に着信アナウンスをフィルタリングします。 IPv4の場合、しきい値は/ 24プレフィックスになる傾向があり、これは256アドレスを意味します。つまり、パブリックインターネットでエニーキャストを行うには、少なくとも256個のアドレスが必要です。
すでに独自の/ 24プレフィックスがある場合、ホスティングプロバイダーがアナウンスするのを止めることはそれほどありません。これが事実である場合、エニーキャスティングは、このサービスを適切な価格で提供することをいとわないさまざまなホスティングプロバイダーの束を見つけるのと同じくらい簡単です。次に、それらすべてにプレフィックスをアナウンスしてもらいます。
アドバタイズされたルートについて公開されている情報を参照して、この種類のサービスを提供する可能性の高いプロバイダーに案内するために、顧客に代わってプレフィックスをすでに発表しているプロバイダーを見つけることができます。ルーティングテーブルでこれを検索する1つのツールは bgp.he.net です。
独自のプレフィックスがなく、プロバイダーからのプレフィックスが必要な場合は、そのプロバイダーに対する上記の制限の意味を理解することが重要です。
プロバイダーには、エニーキャストプレフィックスを設定できる十分なIPアドレスがあります。ただし、いったんそれを実行すると、256個のアドレスすべてをエニーキャストとして使用することに専念します。また、256のアドレスはすべて、まったく同じ場所でホストする必要があります。
このため、エニーキャストサービスにそのうちの1つだけを使用するために、256のアドレスが割り当てられることがあります。これはあなたにとって最初の機会かもしれません。プレフィックスをすでにエニーキャストしているプロバイダーは、実際には250の未使用のエニーキャストアドレスを持っている可能性があります。あなたのサービスがプロバイダーにとって十分に「興味深い」場合、それらはそれらの残りのアドレスの1つであなたをホスティングすることをいとわないかもしれません。重要な注意点の1つは、主要なエニーキャストサービスとまったく同じ場所でホストされる必要があることです。また、ホスティングが必要な場所を決定するのはエニーキャストサービスの主要なサービスであるため、適切と思われるようにサービスを移動する手配が必要になる可能性があります。
上記のほとんどは、プロバイダーがサービスをホストしている場所とプレフィックスをアナウンスしている場所の間でおおよそ1：1の対応を想定しています。
ホスティングプロバイダーが独自の冗長バックボーンと独自のデータセンターを持っている場合、それらをホストしている場所とは異なる場所のセットでプレフィックスをアナウンスすることができます。さらに、内部では、ユニキャストまたはエニーキャストとして、より長いプレフィックスをルーティングできます。
たとえば、プロバイダーが/ 22を4つの異なるPOPでアナウンスし、それらの間に冗長ネットワークがある場合（たとえば、4つのリンクのリング）、内部的に/ 24または/ 25を各POPにルーティングし、/28すべてのPOPにエニーキャストされます（これは、パケットが最初にネットワークに入るPOPによるサービスを受けることを意味します）。
冗長バックボーンとデータセンターの両方を備えたプロバイダーを見つけることができれば、そのようなプロバイダーがサービス用の独自のIPアドレスのいずれかをエニーキャストすることははるかに簡単です。ただし、そうすることで、サービスはバックボーンルータのすべてで1つのCAMテーブルエントリを消費することに注意してください。そして、あなたはそれを支払う必要があります。
TCPとエニーキャスト
一部のコメントで指摘されているように、TCPはステートフルプロトコルです。そのため、Webサービスがステートレスであると見なした場合でも、TCPレイヤーに状態があります。その結果、TCPベースのサービスを単純にエニーキャストすると、ユーザーは非常に頻繁な接続リセットを経験することになります。
この問題は、実際のWebサーバーの前に別のレイヤーを配置することで解決できます。必要なのは、受信されたTCPパケットを適切なWebサーバーに転送し、接続全体で一貫して転送できるノードのレイヤーです。これまでのところ、これは標準のDSRベースのロードバランサーをかなり説明しています。
ただし、このロードバランサーには複数のインスタンスがあるため、状態を共有する必要があります。分散ハッシュテーブルは、このレイヤーで使用できるデータ構造です。
さらに、負荷分散層からのパケットは、変更せずにバックエンドに転送する必要があります。元のパケットの宛先IPに基づくIPルーティングはその問題を解決しません。その宛先アドレスは依然としてエニーキャストアドレスであるため、パケットはバックエンドに到達することはなく、単にロードバランサーに戻り、ループするまでループします。 TTLが期限切れです。
典型的なロードバランサーは、宛先MACアドレスを変更して転送することでこれに対処し、IPルーティングをバイパスします。これが機能するのは、ロードバランサーとバックエンドがすべて1つの場所にあり、それらの間のネットワークが完全に切り替えられており、ロードバランサーとバックエンドの間にルーターがない場合のみです。
ただし、その問題を解決するには別のアプローチがあります。ロードバランサーからバックエンドへのパケットは、IPトンネルを介して送信できます。外部IPヘッダーは、バックエンドを指すユニキャストアドレスである宛先アドレスを伝達します。内部IPヘッダーは変更されておらず、クライアントIPをソースとして、エニーキャストIPを宛先として伝送します。
この設定では、外部ヘッダーのソースIPはほとんど使用されません。原則として、パケットを受信するロードバランサーのユニキャストアドレスであると想定されます。ただし、一部のサービス（facebookなど）は、クライアントIPを内部ヘッダーからソースIPとして外部ヘッダーにコピーします。トンネルパケットによってICMPエラーがトリガーされ、クライアントに直接送信されることがあるので、Facebook側のこの間違いは外部から検出できます。
内部および外部ヘッダーが同じIPバージョンを使用する必要はありません。したがって、ロードバランサーとバックエンドに必要なユニキャストアドレスはすべてIPv6にすることができ、ロードバランサーとバックエンドの数はIPv4アドレスの可用性によって制限されません。
上記のデザインを使用すると、ロードバランサーは通常、このセットアップでハードウェアのごく一部しか必要とせず、エニーキャストアドレスを介して到達する必要があるのはロードバランサーだけであるという利点があります。これは、主に別のサービスに割り当てられたエニーキャストプレフィックスのピギーバックにより、エニーキャストアドレスを短い警告で再配置する必要がある場合、問題が少ないことを意味します。
落とし穴
明らかに、上記の設定は、スタンドアロンのWebサーバーの束を単に展開するよりも複雑です。セットアップが複雑になると、利用できなくなる可能性があります。したがって、代替案よりも信頼性を高めるのに十分なほど堅牢にするために、このようなスキームにある程度の作業を加える必要があります。つまり、これは、個々のWebサービスに対してデプロイされるものではなく、CDNサービスの一部としてデプロイされる可能性が高いものです。
上記の設定よりも簡単なものでエニーキャストTCPを実行しようとすると、接続の途中でルートが変更されるという問題が発生し、結果としてユーザーがリセットを経験する可能性があります。
エニーキャストは、可用性、レイテンシ、およびロードバランシングに役立つ場合があります。しかし、それは特効薬ではありません。エニーキャストは負荷を分散します。ノードを追加することで負荷に応じてスケーリングできます。ただし、エニーキャストによって到達されるノード間でほぼ完全にバランスのとれた負荷を期待しないでください。分散ロードバランシングレイヤーを使用した上記の設定では、ロードバランサー自体が均等にロードされない場合がありますが、バックエンド全体に均等にロードを分散できます。
可用性を単一のエニーキャストIPに依存しないでください。ノードの1つがダウンした場合、ルーティングはそれを自動的にピックアップしない場合があります。これはすべてのクライアントに影響を与えるわけではありませんが、クライアントのサブセットがダウンしているノードにパケットをルーティングする場合があります。したがって、これらのクライアントでは、エニーキャストIPアドレスがダウンしています。冗長性が必要な場合は、複数のエニーキャストIPアドレスが必要です。
接続の途中でルートが変更されない限り、レイテンシは良好です。ただし、TCPハンドシェイクが完了するとすぐに、TCP接続の間、特定のバックエンドを使用するようにコミットされます。パケットは、クライアントからロードバランサー、バックエンド、およびクライアントに送信する必要があります。この三角ルーティングは、レイテンシを増加させる可能性があります。エニーキャストからのレイテンシが短縮され、最も近いバックエンドを選択できるようになりますが、往復に2つではなく3つのレッグがあると、レイテンシが増加する可能性があります。実世界の測定値をたくさん収集するだけで、2つの要素のどちらがより重要であるかがわかります。
この現実的な記事も役立つかもしれません https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality
リアルユーザーモニタリングは、グローバルエニーキャストが地域エニーキャストよりも優れたパフォーマンスを発揮するかどうかを評価するためにLinkedinによって使用されました。最終的に、彼らは、地域ごとに異なるエニーキャストアドレスが使用される地域エニーキャストを実現し、実際に実装しました。彼らはDNSベースのロードバランシングと地域のエニーキャストベースのロードバランシングを組み合わせて使用しています。
上記のソリューションは、サーバーの場所とIDをある程度分離していますが、トンネリングに基づいているため、優れたソリューションです。トンネリングなしで同じ分離アプローチを使用する方がはるかに優れたアプローチになると思いますが、その実装は今回は非常に制限されています。それは例えば活発な研究中ですILNP（Identifier Locator Network Protocol）によるトラフィックエンジニアリングは、これらの絡み合った問題に対する回答を提供します。乾杯
エニーキャストを実行できるネットワークプロバイダーと物理的なWebサーバーハードウェアをコロコロ接続する必要があります。
このルートを使用する場合は、マシンの管理（dracなど）カードへのトンネルを設定して、現場に行く必要がないようにすることもできます。
私たちのウェブサイトのためにこれを行います。