Clever Geek Handbook

CodingFuture + Puppet。 パートV：データベース（cfdb）

cfdb use cases







要するに：



  1. cfdbは、ノードおよびデータベースのクラスターをデプロイおよび自動調整し、高可用性と障害に対する保護を使用してそれらにアクセスするためのモジュールです。
  2. 概念実証として、Percona Server / XtraDB Clusterおよび公式のPostgreSQL + repmgrビルドに基づいて、 MySQLとPostgreSQLがサポートされています。
  3. cgroupsに基づくリソースの分離、 cfnetwork



    モジュールによるネットワークフィルター設定との統合、およびDBMSを使用した厳密なアクセス制御。
  4. 読み取り専用アクセスの競合と負荷分散を最小限に抑えるために、1つのノードに書き込みます。
  5. クラスタの状態と実際のアクセスの実行可能性を自動的に確認します。
  6. 手動および自動ローカルバックアップ、自動データリカバリ。
  7. 既存のデータベースの自動移行のサポート




テーマサイクル：





コンセプトと用語の紹介



cfdb types







抽象構成のエンティティタイプ：









クラスタ構成の詳細は、DBAのライブ作業によってある程度決定されます。すべての変更が行われるメインノードがあります。 この原則によれば、 database



とrole



エンティティは1つのノードでのみ定義でき、残りのノードはセカンダリまたは一般的なアービトレーターとして構成する必要があります。 フェイルオーバー中に変更を加えたい場合、この状況は少し不快感を与える可能性がありますが、一時的な手動変更の可能性を制限するものはありません。







インフラストラクチャのデバッグを統合して簡素化するために、ユニバーサルHAProxyプロキシサービスが透過的に使用されます。 明確な利点は、アプリケーションに特別な変更がない場合、完全に動作するクラスターノードのステータスの高度な監視、DBMSプロセス外のセキュアな通信チャネルの作成（TLSオフロード）、ボックスからの統計データの収集のサポート、アプリケーションカーブからでも許可される接続数の厳格な制限。 HAProxyは、次の場合に自動的にゲームに入ります。









ラバーの「生産的な」リソース（CPU、I / O）とは異なり、主な問題はメモリの割り当てにあります。 このため、可能な最小および最大制限を考慮に入れて、サービスの相対的な重み（優先度）に従ってシステム内のメモリを割り当てるために、ユニバーサルシステムがcfsystem



モジュールに作成されました。 各instance



のプロセスのセットは、独自のcgroup



スライスsystemd



起動されます。 リソース割り当てとファイル記述子の最大数などの制限の管理に加えて、 systemd



はプロセスの保護者としても機能し、異常なクラッシュを自動的に再開します。 ディスク容量については、分離と速度を最大化するために個別のボリュームをマウントすることを引き続き目的としています。







このモジュールのメタ情報は収集され、Puppetファクトとして保存されます。ファクトがターゲットシステムで生成され、デプロイメントの開始時にPuppetDBにロードされることをある程度理解する必要があります。 つまり 変更後にファクトを最新の状態に保つには、再展開が必要です。 アクセスの自動構成、接続数の制限、その他の微妙な違いは、すべての管理対象システムに関するこれらの中央に格納されたファクトから正確に構成されます。 明らかに改善の余地と適切な計画がありますが、これまでのところ。







要点をつかむ



このモジュールは、多面的な本格的なDBMSチューニングとほぼ同じくらい多面的ですcfdbのドキュメントは、機能を部分的に明確にするのに役立ちますが、この記事をすべてロードするのは不要です。







DBMSを上げる



  1. ベースでシステム構成を追加します 

     #   cfdb    classes: [cfdb] #     cfdb::instances: mysrv: type: mysql port: 3306 databases: db1: {} db2: roles: ro: readonly: true custom: custom_grant: 'GRANT SELECT ON $database.* TO $user; GRANT SELECT ON mysql.* TO $user;'
  2. 2回展開します。 これまでのところ-第二段階では、必要な事実が集中化されたベースに収集されます。 


 @db$ sudo /opt/puppetlabs/bin/puppet agent --test; sudo /opt/puppetlabs/bin/puppet agent --test


何が起こったかを把握してみましょう。









クラスターロールへのアクセスを宣言する



  1. アプリケーションでシステム構成を追加する 

     #   cfdb    classes: [cfdb] #    cfdb::access: #  ,   webapp_mysrv_db1: cluster: mysrv role: db1 local_user: webapp max_connections: 100 webapp_mysrv_db2ro: cluster: mysrv role: db2ro local_user: webapp max_connections: 500 config_prefix: 'DBRO_'
  2. クライアントシステムに2回展開します。 自動チェック中にアクセスできないという警告が表示されるはずです。 

     @web$ sudo /opt/puppetlabs/bin/puppet agent --test; sudo /opt/puppetlabs/bin/puppet agent --test
  3. ベースのあるシステムに一度展開します 

     @db$ sudo /opt/puppetlabs/bin/puppet agent --test
  4. 必要に応じて、DBMSをオーバーロードして、デフォルトで100の倍数であるすべての接続の最大数を増やします。 展開プロセス自体が必要なアクションを促します。 

     @db$ sudo /bin/systemctl restart cfmysql-mysrv.service
  5. 最終段階-すべてのアクセスが機能することを確認するために、クライアントシステムに再度展開します。 

     @db$ sudo /opt/puppetlabs/bin/puppet agent --test


何が起こった：









それだけです。DBMSのタイプに大きな違いはありません。 すべてが同じです。







既存のデータディレクトリの移行



以前にインストールされたDBMS構成からの移行の便宜上、 init_db_from



微調整パラメーターの形式で機能が追加されました。 値の形式は、アップグレードプロセスの仕様により、DBMSの種類によって若干異なります。 使用例： 







 cfdb::instances: mymigrate: type: mysql ... settings_tune: cfdb: init_db_from: '/var/lib/mysql' pgmigrate: type: postgresql ... settings_tune: cfdb: init_db_from: '9.5:/var/lib/postgresql/9.5/main/'


ところで、更新されたcfpuppetserver



モジュールはすでにcfdb



を使用cfdb



て高可用性を構成しています。 インストール中に、メタ情報を失うことなくファクトベースが移行されます。







instance



手動操作を実行する



デフォルトでは、ホームフォルダーは/db/{type}_{name}/



になります。ここで、 bin/



ディレクトリーは、標準のmysql



、 psql



、 repmgr



、およびcfdb_



プレフィックスを持つ他のcfdb_



便利なラッパーとともにcfdb_



ます。 それらはroot



として実行できますが、これは同じPostgreSQLの拡張機能を介したスプーフィングの可能性があるため安全ではありません。 データベースをスーパーユーザーとして入力する例： 







 @db$ sudo -u mysql_mysrv /db/mysql_mysrv/bin/cfdb_mysql #     @db$ /db/mysql_mysrv/bin/cfdb_mysql


バックアップと復元



手動でバックアップおよび復元する機能は、 instance



ホームフォルダーの~/bin/cfdb_backup



および~/bin/cfdb_restore



を使用して常に利用できます。 $cfdb::instance::backup = true



、自動定期バックアップが有効になり$cfdb::instance::backup = true



。 チューニングは、 $cfdb::instance::backup_tune



によって行われ$cfdb::instance::backup_tune



。 実装の詳細は、DBMSのタイプによって異なります。 現在、 xtrabackup



はMySQLで使用され、 pg_backup_ctl



はPostgreSQLで使用されています。







注：XB 2.4には問題があります -増分回復には最低1GBの空きメモリが必要です







たとえば、repmgrでホットスタンバイPostgreSQLクラスターを作成してみましょう。



  1. ホスト構成 

     classes: [cfdb] cfdb::instances: pgcluster: type: postgresql port: 5432 #   is_cluster: true databases: - db1
  2. マイナーノードの構成 

     classes: [cfdb] cfdb::instances: pgcluster: type: postgresql port: 5432 #      is_secondary: true

  3. クライアントは、単一ノードの場合とまったく同じ方法で構成されますが、HAProxyは自動的に透過的にゲームに入ります。







  4. 接続されているすべてのシステムに展開します。 さらに2回繰り返します。最初のステップでPuppetDBにファクトをもたらし、2番目のステップでそれを思い浮かべます。 3回目の繰り返しでは、変更はありません。 *クラスターの一部のノードを再起動する必要がある場合、repmgrの場合、 max_connections



    パラメーターとレプリケーションの詳細のため、マスターから開始する必要があります（ ~/bin/cfdb_repmgr cluster show



    ）。


repmgrを使用して典型的なPostgreSQLクラスターをセットアップした人はいますか、違いを感じましたか？







Dockerや外部インフラストラクチャなどのコンテナーとの統合



2つの側面があります。1つ目はDBMS自体であり、2つ目は条件付きでDBMSクライアントです。 静的バージョンでは問題はありませんが、動的に構築する場合は、最初に最大インフラストラクチャを展開し、その後、クォーラムを節約するためにクラスターノードを適切に切断して余分なものを削除する必要があります。







「管理されていない」外部クライアントの場合、パラメーター$cfdb::role::static_access



、集中メタデータを手動でバイパスして、宣言されたアクセスに関する事実を柔軟に設定できます。







合計で何がありますか



明らかに、このアプローチにより、短時間で産業規模でデータベースクラスターを「リベット」および保守できるため、このようなデリケートなエリアでのエラーのリスクが大幅に削減されます。 もちろん、現時点では、集中化されたデータベースにインフラストラクチャメタデータを含めると、展開プロセスが多少複雑になります。 ある段階では、まだ展開されていない部分をすぐに考慮して、これを改善する機会がありますが、すべてに時間があります。 同時に、このPuppetモジュールを使用すると、最適化プロセスと最終構成の調整の両方を制御する非常に柔軟な機能により、最小限の労力で安全で比較的最適に調整されたDBMSを取得できます。 一般的な概念は普遍的であり、必要に応じて他のタイプのDBMSのサポートを簡単に追加できます。







これらすべてのために、データの安全性はそもそもです-自動化には厳しい制限があり、データ損失のリスクがある場合、展開中のプロンプトに従って手動の介入が必要です。







UPD： Habrのマークダウン処理の不具合が修正されました。







More articles:


All Articles