皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。
本日は先日ご紹介したXtract for vmsの続きのお話である、Xtract for dbsのお話をしたいと思います。
こちらのツールについても、実はすでに日本語でツールの使い方を含めてブログに掲載されておりますので、手順に関しては別サイトのリンクでお知らせいたしますが、今回もまたXtract for dbsについてのご説明になります。
前回のブログでXtractのご紹介はしているので、前段の詳しい話は前回のブログを参照していただきたいと思います。
AHVへの仮想マシン移行方法について～Xtract for vmsの紹介～ - LTN Blog 〜 Lenovo Technology Network 〜
それでは、Xtract for dbsの話に移りたいと思います。
１．データベース移行に関する問題点
データベース移行に関する課題ということで、お客様が問題点として思っていることは以下のようなことだと考えられます。
・サードパーティのソフトウェアが必要でしょう！
・データベースのチューニングでDBのエキスパートの時間を割いてしまうのでなはないか？
・環境が変わると今までの設定どおりに動かないんじゃないの？
というように思われますし、実際にお客様は「アプリなんだからどっからでも動いて当然でしょう！」とか、「ミッションクリティカルで動かしているんだから同じような要件でちゃんと移行して！」といわれます。簡単にコメントされても非常に内容としては難しいと思います。
そこで、現状の環境でデータベースの移行はどのようにしているのかを考えて見ましょう。
２．現状のデータベース移行に関して
よくある話で、SQLサーバなどは一般的に移行方法は世の中にかなり出ています。ただし、良くあるのは注意事項ありなどの制限事項が記載されているので、やはり簡単ではないということです。当然スクリプトなどでの対応などもありますが、俗人化するような話になってしまいますし、AWSなどで利用されている移行ツールなどもありますが、クラウド利用ではない方にAWSなどの移行ツールを利用することはないと思います。
ではXtract for dbsについての説明に移りたいと思います。
３．Xtract for dbsを利用したデータベース変換
Xtract for dbsについても、仮想マシンのときと同様でエージェントレスで動作します。また、SQLServerのどのプラットフォームにも対応します。基本は完全移行ではなく、新しくSQLサーバを構築するイメージになります。
移行するデータベースについてもDiscoveryやアセスもしてくれます。
移行プランについても決めることが出来ます。
イメージはこのような感じですが、実際のフローについてもう少し詳しく説明したいと思います。
4．Xtract for dbsを利用したデータベース変換プロセス
まずは物理サーバや仮想サーバで利用しているSQLサーバを用意します。こちらを利用してマイグレーションをするわけですが、このサーバリソースからコンフィグデータやパフォーマンスデータをツールを利用することでデータを採取します。
採取したデータを元にSQLに最適なサイジングを施し、セキュリティ・ネットワーク・ストレージなど最適なものテンプレートをデザインします。
テンプレートを作成して最終的にはBluePrint（設計図）が出来上がります。この設計図を元にSQLの移行を行っていきます。
このプロセスを通すことで以下を実現します。
- SQLサーバのDB移行のベストプラクティス
- 最小限のダウンタイム
- 非常に軽い仮想アプライアンス/Dockerコンテナ
最終的にXtract for dbsをメリットを整理させていただきます。
５．Xtract for dbsにメリットについて
前回のXtract for vmsと同様ですが、Nutanixのユーザは無償で利用することが出来ます。また短期間での移行や1クリックなどの簡易操作による移行でオペレーションへの負担を軽減します。また、物理・仮想を問わずマイグレーションを行うことも可能です。SQLサーバをレプリケーションしてからの移行となりますので、仮想マシンをそのまま変換するものではありません。
データベースの移行で一度検討してみてはいかがでしょうか。
宜しくお願いします。
