スニッチ
Cassandra において、スニッチには2つの機能があります。
-
リクエストを効率的にルーティングするために、ネットワークトポロジについて Cassandra に十分に教えること。
-
関連する障害を回避するために、クラスター全体にレプリカを分散できるようにすること。これは、マシンを「データセンター」と「ラック」にグループ化することによって行われます。Cassandra は、同じ「ラック」（実際には物理的な場所ではない可能性があります）に複数のレプリカが存在しないように最善を尽くします。
動的スニッチ
動的スニッチは、読み取りレイテンシーを監視して、速度が低下したホストからの読み取りを回避します。動的スニッチは、cassandra.yaml で次のプロパティを使用して設定されます。
-
dynamic_snitch: 動的スニッチを有効にするか無効にするか。 -
dynamic_snitch_update_interval: 100 ミリ秒。ホストスコア計算のよりコストのかかる部分を実行する頻度を制御します。 -
dynamic_snitch_reset_interval: 10 分。ゼロより大きい値に設定した場合、キャッシュ容量を増やすために、レプリカをホストに「固定」できます。 -
dynamic_snitch_badness_threshold:: 不良さのしきい値は、固定されたホストがどれだけ悪くなったら、動的スニッチが他のレプリカを優先するかを制御します。これは、パーセンテージを表す double として表されます。したがって、0.2 の値は、固定されたホストが最速よりも 20% 悪くなるまで、Cassandra が静的スニッチの値を優先し続けることを意味します。
スニッチクラス
cassandra.yaml の endpoint_snitch パラメータは、動的スニッチによってラップされ、2つのエンドポイントが同じデータセンターにあるか、同じラックにあるかを判断する IEndpointSnitch を実装するクラスに設定する必要があります。すぐに使えるように、Cassandra は次のスニッチ実装を提供します。
- GossipingPropertyFileSnitch
-
これは、本番環境で使用するための適切なスニッチです。ローカルノードのラックとデータセンターは、cassandra-rackdc.properties で定義され、gossip を介して他のノードに伝播されます。
cassandra-topology.propertiesが存在する場合、フォールバックとして使用され、PropertyFileSnitch からの移行を可能にします。 - SimpleSnitch
-
戦略順序を近接として扱います。これにより、読み取り修復を無効にするときにキャッシュの局所性が向上します。単一データセンターのデプロイメントにのみ適しています。
- PropertyFileSnitch
-
近接は、
cassandra-topology.propertiesで明示的に設定されたラックとデータセンターによって決定されます。 - RackInferringSnitch
-
近接は、各ノードの IP アドレスの 3 番目と 2 番目のオクテットにそれぞれ対応すると想定されるラックとデータセンターによって決定されます。これがデプロイメント規則と一致しない限り、これはカスタム Snitch クラスを作成する例として最適であり、その精神で提供されています。
クラウドベースのスニッチ
これらのスニッチは、さまざまなクラウドベンダーのクラウド環境で使用されます。すべてのクラウドベースのスニッチ実装は、現在 AbstractCloudMetadataServiceSnitch （さらに AbstractNetworkTopologySnitch を拡張）を拡張しています。
各クラウドベースのスニッチには、それぞれのノードがどのラックとデータセンターに属するかを解決する独自の方法があります。AbstractCloudMetadataServiceSnitch は、それを実現するための最も一般的な機構をカプセル化します。すべてのクラウドベースのスニッチは、それぞれのクラウドに固有の HTTP サービスを呼び出します。AbstractCloudMetadataServiceSnitch のコンストラクタは、HTTP URL に対して HTTP GET リクエストを、HTTP ヘッダーを送信せずに実行し、HTTP コード 200 の応答を期待するメソッド apiCall を実装する AbstractCloudMetadataServiceConnector の実装を受け入れます。実装者がそれを望む場合、リクエストの一部としてさまざまな HTTP ヘッダーを送信できます。
現在、AbstractCloudMetadataServiceConnector の唯一の実装は DefaultCloudMetadataServiceConnector です。ユーザーが AbstractCloudMetadataServiceConnector の動作をオーバーライドする必要がある場合は、独自のコネクタを実装して AbstractCloudMetadataServiceSnitch のコンストラクタに伝播することで、これを行うことができます。
すべてのクラウドベースのスニッチは、cassandra-rackdc.properties で次のプロパティを受け入れます。
- metadata_url
-
トポロジ情報を取得するクラウドサービスの URL。これはクラウド固有です。
- metadata_request_timeout
-
30 秒（30 秒）のデフォルト値は、apiCallによる呼び出し時に接続タイムアウトを設定します。言い換えれば、metadata_urlに対するリクエストは、その期間内に応答が到着しないとタイムアウトします。 - dc_suffix
-
解決されたデータセンターに追加される文字列。デフォルトでは空です。
組み込みのクラウドベースのスニッチは次のとおりです。
- Ec2Snitch
-
単一のリージョン内の EC2 デプロイメント、またはリージョン間 VPC が有効な複数のリージョンでの EC2 デプロイメントに適しています (2017 年末以降に利用可能。 AWS の発表を参照)。EC2 API からリージョンとアベイラビリティーゾーンの情報をロードします。リージョンはデータセンターとして扱われ、アベイラビリティーゾーンはラックとして扱われます。プライベート IP のみが使用されるため、リージョン間 VPC が有効になっている場合にのみ、複数のリージョンで機能します。
- Ec2MultiRegionSnitch
-
リージョン間の接続を許可するために、パブリック IP を broadcast_address として使用します（したがって、シードアドレスもパブリック IP に設定する必要があります）。パブリック IP ファイアウォールで
storage_portまたはssl_storage_portを開く必要があります（リージョン内のトラフィックの場合、Cassandra は接続を確立した後、プライベート IP に切り替えます）。
Ec2 スニッチの場合、CASSANDRA-16555以降、AWS IMDS のバージョンを選択できます。デフォルトでは、IMDSv2 が使用されます。IMDS のバージョンは、プロパティ ec2_metadata_type によって駆動され、v1 または v2 のいずれかの値を指定できます。IMDS のカスタム URL を ec2_metadata_url (または metadata_url) で指定できます。これはデフォルトでは 169.254.169.254 であり、/latest/meta-data/placement/availability-zone エンドポイントに対してクエリが実行されます。
IMDSv2 は、最初に IDMSv2 からフェッチする必要があるトークンによって保護されており、IDMSv2 への実際のクエリのヘッダーで渡す必要があります。Ec2Snitch と Ec2MultiRegionSnitch はこれを自動的に行います。ユーザーに公開される唯一の設定パラメータは ec2_metadata_token_ttl_seconds であり、デフォルトでは 21600 に設定されています。TTL は範囲 [30, 21600] の整数である必要があります。
- AlibabaCloudSnitch
-
ECS リージョンが DC であり、ECS availability_zone がラックであると想定するスニッチ。この情報は、ノードの設定で利用できます。ゾーン ID の形式は
cn-hangzhou-aのようになります。ここで、cnは中国を意味し、hangzhouは杭州リージョンを意味し、aは az ID を意味します。cn-hangzhouを dc として、aをゾーン ID として使用します。このスニッチのmetadata_urlは、デフォルトでは100.100.100.200/であり、エンドポイント/latest/meta-data/zone-idに対して HTTP リクエストを実行します。 - AzureSnitch
-
Azure Snitch は、デフォルトで API バージョン
2021-12-13の/metadata/instance/compute?api-version=%s&format=jsonエンドポイントを169.254.169.254のmetadata_urlに対して呼び出し、JSON 形式で応答を返すことで、データセンターとラックを解決します。API のバージョンは、cassandra-rackdc.propertiesのプロパティazure_api_versionを介して設定できます。データセンターは応答のlocationフィールドから解決され、ラックは最初にzoneフィールドを調べることで解決されます。zoneが設定されていない場合、または空の文字列の場合、platformFaultDomainフィールドを調べます。このような解決された値は、rack-文字列が前に付けられます。 - GoogleCloudSnitch
-
Google スニッチは、
metadata.google.internalのmetadata_urlに対して/computeMetadata/v1/instance/zoneエンドポイントを呼び出すことで、データセンターとラックを解決します。
