要するに：

1. cfdbは、ノードおよびデータベースのクラスターをデプロイおよび自動調整し、高可用性と障害に対する保護を使用してそれらにアクセスするためのモジュールです。
2. 概念実証として、Percona Server / XtraDB Clusterおよび公式のPostgreSQL + repmgrビルドに基づいて、 MySQLとPostgreSQLがサポートされています。
3. cgroupsに基づくリソースの分離、 cfnetworkモジュールによるネットワークフィルター設定との統合、およびDBMSを使用した厳密なアクセス制御。
4. 読み取り専用アクセスの競合と負荷分散を最小限に抑えるために、1つのノードに書き込みます。
5. クラスタの状態と実際のアクセスの実行可能性を自動的に確認します。
6. 手動および自動ローカルバックアップ、自動データリカバリ。
7. 既存のデータベースの自動移行のサポート

テーマサイクル：

• パートI：ネットワークおよびネットワークフィルター（cfnetwork + cffirehol）
• パートII：アクセスと標準環境（cfauth + cfsystem）
• パートIII：Puppet Server（cfpuppetserver）のインストール
• パートIV：集中管理（cftotalcontrol）
• パートV：データベース（cfdb）
• パートVI：現在のブラックリストと保護されたノッキング

コンセプトと用語の紹介

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

• cluster -単一のユニットとして機能するDBMSノードの抽象的な名前付きコレクション。
• instanceはclusterが所有する物理ノードです。
• databaseはclusterが所有する名前付きデータベースです。
• role -特定のdatabaseへのアクセス権を持つアカウント。 デフォルトでは、対応するデータベースへのフルアクセスを持つdatabaseと同じ名前のロールが常に存在します。
• access -特定のノードの指定されたローカルアカウントからの接続の特定の最大数を持つ特定のデータベースアカウントで特定のデータベースにアクセスする必要性が宣言されます。

クラスタ構成の詳細は、DBAのライブ作業によってある程度決定されます。すべての変更が行われるメインノードがあります。 この原則によれば、 databaseとroleエンティティは1つのノードでのみ定義でき、残りのノードはセカンダリまたは一般的なアービトレーターとして構成する必要があります。 フェイルオーバー中に変更を加えたい場合、この状況は少し不快感を与える可能性がありますが、一時的な手動変更の可能性を制限するものはありません。

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

• clusterは複数のノードがあるため、それぞれのステータスを制御する必要があります。
• アクセス宣言宣言には、リモートホストとの安全な通信チャネルが強制的に必要です。
• クライアントとサーバーのノードのcf_location一致しない（異なるデータセンター）ため、VPNの場合、安全でない接続は明らかに示されません。

ラバーの「生産的な」リソース（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 

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

• Percona Serverパッケージの完全なリストがインストールされます。
• 一意の名前mysrvを持つ抽象クラスターに属するDBMSノードを作成します
• クラスターでは、2つのデータベースdb1とdb2を定義します
• ロールdb1およびdb2は、対応するデータベースへのフルアクセスで自動的に作成されます
• さらに、 db2roロールがdb2ro 、 db2への読み取り専用アクセスとノード間の負荷分散がサポートされます。
• さらに、完全に任意のアクセス権でdb2customロールがdb2customます。 $databaseと$userワイルドカードキーの必須の使用に注意してください。
• すべてのパスワードはランダムに生成されますが、強制することができます。
• 集中PuppetDBデータベースでは、既存のクラスター、そのノード、データベース、およびロールに関する情報が表示されます。

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

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 

何が起こった：

• クライアントシステムで、ローカルwebappユーザーの下に.envファイルが作成されました。
  
  • データベースと同じ名前のdb1ロールにアクセスするためのDB_プレフィックス（デフォルト）が付いた変数のセットが含まれています。
  • さらに、 DBRO _データベースのdb2roロールにアクセスするためのDBRO _プレフィックス付きの変数セット、
  • 必要に応じて、 .envに加えて、特定のアプローチを使用できます（ cfdb::access::custom_config参照）。
• 2番目のパスで、ファクトをロードします。
• 次に、DBMS構成を更新します。ここで、各ロールに対して、許可されたリストにクライアントノードが追加され、接続の最大数が増加します。
• すべてのアクセスが機能することを確認します-展開時に自動的に行われます

それだけです。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のマークダウン処理の不具合が修正されました。