web-dev-qa-db-ja.com

openvzコンテナ内の大量生産のMySQL / Perconaデータベース

そのため、現在、次の仕様でMySQL5.1データベースを実行しています。

  • 手順:Intel(R)Xeon(R)CPU E5-1620 0 @ 3.60GHz
  • RAM:64 Go
  • ディスク:2x 100 Go SSD(RaidSoft)

物理サーバーとmysqlサーバーをperconaサーバー5.6に移行することを計画しています。

残りのインフラストラクチャにProxmoxクラスターを使用しているため、新しいMySQLサーバーを専用のopenvzコンテナー(ホスト上に1つのみ)に配置したいと思います。

私はすでにこれをセットアップすることに成功しました、そしてそれはうまくいくようです、しかし私はそれが良い考えであるかどうかまだ疑問に思っています。

フィードバックはありますか?

1
Trent

多くのディスクI/Oが発生する可能性のある操作には、OpenVZ(Proxmoxなど)の使用に注意してください。経験から、非常に非常に遅いことがわかります。場合によっては、ネイティブハードウェアの約半分の速度です。これは書き込みでは特に悪く、サーバー上で読み取りと書き込みを行うコンテナーが増えるほど悪化します(後者の部分はあなたの場合には当てはまらないと思います)。

また、MySQLは非常にリソースを消費するため、適切に設定しないと、OOMが強制終了されるか、コンテナの制限に達する可能性があることに注意してください。繰り返しますが、経験から、これを行うのは難しい場合があります。また、hugepagesなど、MySQLのパフォーマンスを向上させるための特定の項目をコンテナー内から設定できないため、ホストからゲストに切り替えてしまう可能性があるという事実もあります。

MySQLをコンテナに入れることで得られるのは、プロセスの分離(実際にはそうではありません)、コンテナがノードを停止しないという穏やかな保証(ただし保証はありません)、制御するための優れたインターフェイスだけです。サーバーに(OpenVZコンテナーに固有ではない)があり、正しく構成するまでは多くの頭痛の種があります。私はこの特定の用途のためにOpenVZを避けます。

Proxmoxの使用に行き詰まっている場合は、OpenVZコンテナーの代わりにKVMをこの目的で使用することをお勧めします。頭痛の種が少なくなるので、私を信じてください。

1
deriamis

重い本番サーバーの場合、コンテナーを使用する意味がわかりません。私の経験には本当の利点はありません。たぶん、コンテナに1つまたはいくつかのスレーブを配置することは理にかなっていますが、マスター、私はそれをベアメタルに配置します。 perconaクラスターをチェックしてください。それは揺れる。

VMを使用したい理由は何ですか?ビジネスケースは何ですか?

0
gmck

コンテナでMySQLを実行することにはいくつかの利点があります。

PVEコンテナにはいくつかの利点があります。-DBサーバーを管理し、他には何も影響を与えません-別の物理ホストに簡単に移動します(共有ストレージを使用している場合はオンライン)-PVEでバックアップしますが、私の意見ではxtrabackupまたはIdera HotCopyの方が優れています-実行マスタースレーブレプリケーションシナリオでは、それらのうち2つ以上が「ライブ」バックアップSQLサーバーになりますが、同じ物理サーバー上にある場合、これにより単一障害点が作成されます。

Proxは非常に信頼性が高く、それについては疑いの余地がありません-私は800日以上の稼働時間を持つproxmoxサーバーを持っています。コンテナーで実行する場合、パフォーマンスへの影響はわずかです。 cpuコアをVMに割り当てて、innodbがそれらを利用できるようにしてください。

0
GMcK

「パフォーマンス上の理由で実行しない」に対応して、書き込みが非常に多い環境(70%INSERT)でProxmoxを使用し、目立たないディスク(WD Red)にRAID-10バックエンドを配置し、他のいくつかのビジー状態のVMを使用します。 (OpenVZおよびKVM)、書き込みパフォーマンスの問題はありません(iodelayが0%を超えることはめったにありません)。パフォーマンスのみを考慮している場合、基盤となるハードウェアが適切であれば、問題は発生しません。

賢明なメリット-オンライン移行、スナップショットバックアップ、ドライブスペースの拡張...すべてが揃っています。

Proxmoxの信頼性については、別のポスターしかエコーできません。

稼働時間

19:51:09 785日、22:59、1ユーザー、平均負荷:4.92、4.81、4.79

稼働時間

19:51:55アップ142日、4:56、1ユーザー、負荷平均:0.05、0.07、0.05

0
Lee S