ベスト・プラクティス・ルールのリファレンス
Best Practice Service(ベスト・プラクティス・サービス)で使用可能なルールのリファレンス。
Best Practice Service(ベスト・プラクティス・サービス)で使用可能なルールのリファレンスが、アドバイザーのセクションごとにアルファベット順に整理されています。
バックアップ・アドバイザー
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
自動スナップショットが有効になっていない | 実稼働環境で自動スナップショットがオフになっていないかどうかをチェックします。 | 高 | ノード | 毎日 | 情報 |
自動スナップショットが有効になっていないと、TRUNCATEまたは削除時にデータが失われる可能性があります。auto_snapshot を有効にしてデータ喪失を防ぐには、cassandra.yamlを更新してください。ヒント: LCM構成プロファイルを使用して、cassandra.yamlの[Snapshots]セクションで[auto_snapshot]を有効にします。[auto_snapshot]設定は、LCM構成プロファイルでデフォルトで有効になっています。 |
|||||
コミット・ログ・アーカイブ設定有効化の整合性 注: このルールは、DataStax Enterprise 6.1以降で使用できます。 |
クラスター内のすべてのノードで設定が一貫していないため、コミット・ログ・アーカイブがオフになっています。 | 高 | ノード、クラスター | 毎時 | アラート |
コミット・ログ・アーカイブがクラスター内のすべてのノードで有効になっていないため、特定時点まで復元するとデータが失われる可能性があります。クラスター内のすべてのノードでコミット・ログ・アーカイブの設定が有効になるように、再度コミット・ログ・アーカイブをオンにします。 |
構成アドバイザー
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
Repair Service(リペア・サービス)が有効になっていない | Repair Service(リペア・サービス)が有効になっているかどうかを確認します。 | 高 | クラスター | 毎日 | 情報 |
定期的にリペアを実行することで、クラスター内のデータの整合性を維持できます。Repair Service(リペア・サービス)を有効にします。 | |||||
Repair Service(リペア・サービス)が正しく構成されていない | クラスターでRepair Service(リペア・サービス)が正しく構成されているかどうかを確認します。詳細については、基本、高度、およびエキスパートのリペア構成を参照してください。 | 高 | クラスター | 毎日 | 情報 |
OpsCenter Repair Service(OpsCenterリペア・サービス)を、クラスターで構成されている最小のgc_grace 期間内に実行することを推奨します。 |
|||||
DataStaxエージェントでセキュリティが有効になっていない | デーモンとエージェント間でSSLとともにOpsCenter認証が有効になっているかどうかをチェックします。 | 高 | クラスター | 毎日 | アラート |
エージェントとの通信用にSSLを有効にしてください。 | |||||
スワップ領域が有効になっている | スワップ領域が有効になっているノードがないかどうかをチェックします。実稼働環境ではスワップ領域を使用しないでください。 | 中 | ノード | 毎日 | アラート |
スワップ領域を無効にしてください。 | |||||
シード・ノードの構成 | 各データ・センターで、そのデータ・センターに少なくとも2つのノードが存在する場合、少なくとも2つのシード・ノードが存在する必要があります。ホスト名ではなくIPを使用する必要があります。すべてのノードが同じシード・リストを持っている必要があります。 | 低 | ノード、クラスター | 毎日 | アラート |
この問題を修正するには、すべてのノードで同じIPシード・リストを使用してください。 |
ネットワーク・アドバイザー
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
リッスン・アドレスとRPCアドレスが異なる | Cassandraがリッスン・アドレスとRPCアドレス用に別のネットワークを使用するように構成されている、複数のネットワーク・インターフェイスがあるかどうかをチェックします。 注: cassandra.yamlファイルの listen_address フィールドを空白のままにすると、OpsCenterバージョン6.1.2以降では、OpsCenterエージェントは、デフォルトでDSEと同じリッスン・アドレスに設定されます。 |
中 | ノード | 毎日 | 情報 |
複数のネットワークが検出されましたが、クライアントとの通信と内部ユーザーとの通信に同じネットワークを使用しています。 |
OpsCenter構成アドバイザー
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
OpsCenterフェイルオーバーが有効になっている | DataStaxは、高可用性を確保するためにOpsCenterフェイルオーバーの構成を推奨します。 | 低 | OpsC | 毎日 | アラート |
OpsCenterバックアップ・インスタンスが構成されていません。OpsCenterのフェイルオーバーを有効にしてください。 |
OSアドバイザー
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
クラスターのクロックが同期されていない | クラスター内のすべてのクロックが2秒のトレランス内で同期されているかどうかをチェックします。 | 高 | ノード、クラスター | 毎日 | アラート |
クラスター内の合計ドリフトが2秒のトレランスを超えています。ノードのクロックを同期してください。 警告: クロック・ドリフトは、LCMがSSL証明書を生成しようとするときに問題を生じる可能性があります。データベースの操作とロギングの正確なタイムスタンプを確保するには、クロックの同期状態を維持することが重要です。 |
|||||
Cassandraユーザーとエージェント・ユーザーの一致 | Cassandraとエージェントが同じユーザーに実行されているかどうかをチェックします。 | 高 | ノード | 毎日 | アラート |
Cassandraとエージェントが同じユーザーに実行されていません。Cassandraとエージェントが同じユーザーに実行されていることを確認してください。 | |||||
クロックがUTCになっている | ノードのクロックが協定世界時(UTC)になっているかどうかをチェックします。 | 低 | ノード | 毎日 | アラート |
協定世界時(UTC)になっていないノードがあります。すべてのノードがUTCになっていることを確認してください。 | |||||
Oracle Javaが必要 | ノードでOracle Javaが使用されていることをチェックします。 | 中 | ノード | 毎日 | アラート |
サポートされていないJDKがノードで使用されています。DataStax Enterpriseで使用され、十分にテストされている推奨のJDKは、Oracle/Sun Hotspot JDKです。OpenJDK(Linux OSのデフォルトのJava環境)を使用している場合は、Oracle Hotspot JDKに切り替えてください。 ヒント: LCM構成プロファイルを使用してJavaインストールを管理します。 |
パフォーマンス・アドバイザー
ノードに対する読み取り/書き込みパフォーマンスのルール(パフォーマンス・アドバイザーとPerformance Service(パフォーマンス・サービス)を混同しないでください)。
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
読み取り要求タイムアウトが最適でない | ノードの読み取り要求タイムアウトが推奨値を超える値に設定されていないかどうかをチェックします。 | 中 | ノード | 毎日 | アラート |
ノードの読み取り要求タイムアウトを大幅に増やすことは推奨されません。ノードのcassandra.yamlを更新して、read_request_timeout_in_msの値を小さくしてください。 | |||||
書き込み要求タイムアウトが最適でない | ノードの書き込み要求タイムアウトが推奨値を超える値に設定されていないかどうかをチェックします。 | ||||
ノードの書き込み要求タイムアウトを大幅に増やすことは推奨されません。ノードのcassandra.yamlを更新して、write_request_timeout_in_msの値を小さくしてください。 | |||||
範囲要求タイムアウトが最適でない | ノードの範囲要求タイムアウトが推奨値を超える値に設定されていないかどうかをチェックします。 | 中 | ノード | 毎日 | アラート |
ノードの範囲要求タイムアウトを大幅に増やすことは推奨されません。ノードのcassandra.yamlを更新して、range_request_timeout_in_msの値を小さくしてください。 |
Performance Service(パフォーマンス・サービス) - スロー・クエリー・アドバイザー
詳細については、「Performance Service(パフォーマンス・サービス)」の「スロー・クエリー」を参照してください。
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
プリペアド・ステートメントの使用 | プリペアド・ステートメントを使用すると、クエリー解析のオーバーヘッドを取り除いてコーディネーターのワークロードが軽減されます。 | 中 | クラスター | 毎時 | 情報 |
クエリーにはプリペアド・ステートメントを使用してください。 | |||||
ALLOW FILTERINGを使用しない | クエリーでALLOW FILTERINGが使用されていないかどうかをチェックします。 | 中 | クラスター | 毎時 | 情報 |
ALLOW FILTERINGを使用すると、クエリーはトークン範囲内のすべてのデータをスキャンします。これは、分析ワークロードでは必要ですが非分析ワークロードでは推奨されません。ALLOW FILTERINGにより、クエリーの実行時間が長引き、システム・リソースを過剰に消費する可能性があります。分析ワークロードの外部でALLOW FILTERINGを使用する場合は、代わりにクエリー・パターンに基づくデータ・モデルを新たに検討してください。 | |||||
大きなバッチを使用しない | 大きなバッチを使用すると最適化できるように思えますが、コーディネーターに余分な負荷がかかり、クラスター内にホットスポットが生じる可能性があります。大きなバッチは個々のクエリーに分割し、異なるノードに分散させると、クエリーの実行速度が上がります。 | 中 | クラスター | 毎時 | 情報 |
バッチを個々のクエリーに分割し、異なるノードに分散させます。 | |||||
カウントではなくカウンターを使用する | count(*)クエリーは、小さい値に制限しても高負荷になる可能性があります。 | 中 | クラスター | 毎時 | 情報 |
管理するカウンターとロジックを置き換えます。 | |||||
IN句のキー数を最小限に抑える | 大量のIN句は1つのクエリーのように見えますが、実際には複数のクエリーとして実行されます。 | 中 | クラスター | 毎時 | 情報 |
なるべく多くのコーディネーターに個々の非同期クエリーを分散させます。 |
Performance Service(パフォーマンス・サービス) - テーブル・メトリクス・アドバイザー
詳細については、「Performance Service(パフォーマンス・サービス)」の「テーブル・メトリクス」を参照してください。
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
大きなパーティション | 過度に大きなパーティションがないかどうかをチェックします。過度に大きなパーティションがあると、パフォーマンスに悪影響を与えるため、推奨されません。サイズが100 MBを超えるパーティションは、大きいと見なされます。 | 低 | ノード、クラスター | 毎時 | アラート |
過度に大きなパーティションがあると、パフォーマンスに悪影響を与えるため、推奨されません。大きなパーティションを分割するようにデータ・モデルの変更を検討してください。 | |||||
セカンダリ・インデックス・カーディナリティ | セカンダリ・インデックスの固有値が多すぎないかどうかをチェックします。 | 低 | ノード、クラスター | 毎時 | アラート |
セカンダリ・インデックスのカーディナリティが高いと、システムのパフォーマンスに悪影響を与える可能性があります。インデックス付きデータを非正規化することを検討してください。 | |||||
トゥームストーン数 | 読み取り中に処理されるトゥームストーンの数。 | 低 | ノード、クラスター | 毎時 | アラート |
トゥームストーンが多いとパフォーマンスが低下する可能性があります。これにより、クエリーが失敗することもあります。 | |||||
コンパクション・ストラテジ | データと環境に基づいたコンパクション・ストラテジを使用する必要があります。このベスト・プラクティス・ルールは、実行することでコンパクション・ストラテジの選択の重要性を認識できるように設定されています。環境に基づいた正しいコンパクション・ストラテジが既に選択されていて、コンパクション・ストラテジに関するリマインダーを表示する必要がない場合は、このルールを無効にしてください。 | 低 | クラスター | 毎時 | アラート |
データと環境に最も適したコンパクション・ストラテジを選択します。 |
Performance Service(パフォーマンス・サービス) - スレッド・プール・アドバイザー
詳細については、「Performance Service(パフォーマンス・サービス)」の「スレッド・プール統計」を参照してください。
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
読み取りステージ | 保留中の読み取りの数。 | 低 | ノード | 毎時 | アラート |
保留中の読み取りが多すぎます。これは、ディスクの問題、調整不良、またはクラスターの過負荷に関係している可能性があります。新しいノードの追加、システムの調整、データ・モデルの再考を検討してください。CPUまたはIOバウンドでない場合は、concurrent_reads を大きくしてください。 |
|||||
ミューテーション・ステージ | 保留中のミューテーションの数。 | 低 | ノード | 毎時 | アラート |
保留中のミューテーションが多すぎます。これは、ディスクの問題、調整不良、またはクラスターの過負荷に関係している可能性があります。新しいノードの追加、システムの調整、データ・モデルの再考を検討してください。CPUまたはIOバウンドでない場合は、concurrent_writes を大きくしてください。 |
|||||
ReplicateOnWriteStageストレス | CL.ONEカウンター・インクリメントでは、インクリメントが完了した後に、読み取りを含む非同期タスクが開始されるため、CL.ONEカウンター・インクリメントを使用する場合は注意してください。このプール内のプロセスが多いと、書き込みがブロックされます。 | 中 | ノード | 毎時 | 情報 |
CL.ONEカウンター・インクリメントの使用を減らすか、Cassandra 2.1以降にアップグレードしてください。 |
レプリケーション・アドバイザー
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
レプリケーション係数が許容範囲外 | クラスターのレプリケーション係数がサポート範囲を超えていないかどうかをチェックします。 | 情報 | クラスター | 毎日 | 情報 |
総レプリケーション係数がノード数を超えているキースペースをリストします。キースペースが適切になるようにレプリケーション係数を更新するか、クラスターにノードを追加してください。 | |||||
SimpleSnitchの使用の検出 | 実稼働環境でSimpleSnitchが使用されていないかどうかをチェックします。 | 中 | ノード | 毎日 | 情報 |
SimpleSnitchは、データ・センターやラックの情報を認識しないため、実稼働クラスターには推奨されません。スニッチをトポロジーに対応したスニッチに更新してください。 | |||||
SimpleStrategyキースペースの使用の検出 | SimpleStrategyをマルチ・データ・センター環境のキースペースに使用していないかどうかをチェックします。 | 中 | クラスター | 毎日 | アラート |
NetworkTopologyStrategyを使用するには、関連するキースペースのレプリケーション・ストラテジを更新してください。 |
Searchアドバイザー
Solr Searchノードに関するアドバイス。詳細については、「DSE Search」を参照してください。
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
vnodeがSearchノードで有効になっている | バージョン4.8以前のDataStax Enterprise Searchノードでvnodeが使用されていないかどうか、またはバージョン5.0以降のDataStax Enterprise Searchノードに16個または32個のvnodeがあるかどうかをチェックします。 | 高 | ノード | 毎日 | アラート |
バージョン4.8以前の場合は、現在vnodeが有効になっているSearchノードを、vnodeのないノードと置き換えてください。バージョン5.0以降の場合は、正しい数のvnodeを持つノードと置き換えてください。 | |||||
Searchノードが不適切なautocommitで有効になっている | 実行中のSolrノードのautocommitが5~10秒かどうかをチェックします。 | 中 | クラスター | 毎日 | アラート |
autocommitのしきい値を5~10秒に変更してください。 | |||||
クエリー結果キャッシュが設定されたSearchノードが有効になっている | 実行中のSolrノードのクエリー結果キャッシュが無効になっているかどうかをチェックします。 | 中 | クラスター | 毎日 | アラート |
queryResultCacheを無効にするように、Solr構成クエリーを変更してください。 | |||||
Searchノードのフィルター・キャッシュ・サイズが不適切 | 実行中のSolrノードのフィルター・キャッシュ・サイズが適切かどうかをチェックします。 | 中 | クラスター | 毎日 | アラート |
solr.LRUCacheを使用している場合は、フィルター・キャッシュのsize 属性を128に変更してください。それ以外で、solr.search.SolrFilterCacheを使用する場合は、highWaterMarkMB 属性を256に変更してください。 |
|||||
行キャッシュが設定されたSearchノードが有効になっている | Solrノードの行キャッシュが有効になっているかどうかをチェックします。 | 中 | ノード | 毎日 | アラート |
Solrを使用したDSE Searchのメモリー使用量を最適化するには、行キャッシュを無効にする必要があります。cassandra.yamlファイルを編集して行キャッシュを無効にします。 | |||||
Searchノードのキー・キャッシュ・サイズがデフォルト | Solrノードのキー・キャッシュがデフォルト・サイズに設定されているかどうかをチェックします。 | 中 | ノード | 毎日 | アラート |
Solrを使用したDSE Searchのメモリー使用量を最適化するには、キー・キャッシュのサイズをデフォルトに設定する必要があります。cassandra.yamlファイルを編集して、キー・キャッシュのサイズを推奨デフォルト・サイズに設定します。 | |||||
Searchノードのヒープ・サイズが不適切 | Solrノードのヒープ・スペースが十分かどうかをチェックします。 | 中 | ノード | 毎日 | アラート |
Solrを使用したDSE Searchのメモリー使用量を最適化するには、ヒープを少なくとも14GBに設定する必要があります。Solrノードの最大ヒープは、少なくとも14GBに設定してください。 |
セキュリティ・アドバイザー
ルール | 説明/推奨事項 | 重要度 | 範囲 | 間隔(デフォルト) | アラート・レベル |
---|---|---|---|---|---|
セキュリティ・キースペースが正しくレプリケートされていない | PasswordAuthenticatorを使用しているときに認証キースペースが正しくレプリケートされているかどうかをチェックします。 | 高 | ノード、クラスター | 毎日 | アラート |
system_auth キースペースのレプリケーションを大きくしてください。 |
|||||
セキュリティ・スーパーユーザーの設定がデフォルトになっている | デフォルトのcassandraスーパーユーザーとパスワードがデフォルトから変更されているかどうかをチェックします。 | 高 | クラスター | 毎日 | アラート |
セキュリティ・スーパーユーザーの設定がデフォルトになっています。ユーザー「cassandra」のパスワードを更新してください。 | |||||
セキュリティ認証設定が不適切 | cassandra認証が有効で、AllowAllAuthenticatorに設定されていないかどうかをチェックします。 | 中 | ノード | 毎日 | アラート |
AllowAllAuthenticatorではセキュリティ・チェックが行われないため、推奨されません。ノードのcassandra.yamlで、オーセンティケーターをorg.apache.cassandra.auth.AllowAllAuthenticatorからorg.apache.cassandra.auth.PasswordAuthenticatorに変更してください。 | |||||
OpsCenter認証設定が正しくない | DatastaxEnterpriseAuthを使用している場合にOpsCenter認証がデフォルトに設定されていないかどうかをチェックします。 | 高 | クラスター | 毎日 | アラート |
OpsCenterの認証の管理者ユーザーのデフォルト・パスワードを変更してください。 | |||||
機密構成値の暗号化 | cassandra.yamlの機密構成値の暗号化を有効にすることを推奨します。 | 中 | ノード | 毎日 | 情報 |
構成値の暗号化が有効になっていません。ルールがノード(listed failed nodes)で失敗しました。 dse.yamlで、 config_encryption_active をtrueに設定し、dsetool encryptconfigvalueを使用して機密フィールドの暗号化された構成値を作成します。DSE管理者向けドキュメントの「機密構成ファイル値の暗号化」を参照してください。 |