Find Communities by: Category | Product

日本語コミュニティ

6 Posts authored by: makoto

 あまり派手に宣伝されているのを見たことはありませんが、Oracle 12c で強化された機能に "Storage Snapshot Optimization" というのがあります。「Hot Backup 機能を使わずに取得したストレージベースの複製に対して、アーカイブログ等の適用を行いロールフォワードできる」機能です。

今回は、実際にやってみた手順も合わせて記載させていただきます(最近このパターンが多いですね。自分が楽しいから試しているのですが)

 

Hot Backupが無いといいことがあるのか?

 Hot Backup モード中は書き込み量も増えますし、スクリプトで制御する場合には作りもいくらか複雑になります。Hot Backupモードを使わなくても後からRECOVER DATABASEできるとなれば、DBに対して定期的にクラッシュコンシステントイメージを取得しておき、あとはアーカイブログをこまめに保護しておくだけでよい、という運用が可能になります。リストアについても、バックアップ取得時点に戻りたければ、クラッシュコンシステントの複製イメージを使う。ロールフォワードしたければ、アーカイブログを適用する。という感じでしょうか?もちろん、制御ファイルやSPFILEも普段通り保護しておくことをオススメします。

(あとでもう少し記載しますが、完全回復もできるのですが、現実的な運用としては不完全回復をベースにするのが現実的と思います。つまり、保護しておいた最新のアーカイブログまでの戻し、あるいは必要に応じてその手前のポイントイン・タイムでの戻し、という形が現実的かと思います

 

どんなストレージでも使えるのか?

 Oracle社としても、きちんとストレージベンダーが守るべきスナップショットの要件を提示していますので、Storage Snapshot Optimizationを使おうとすると、弊社のようなベンダーはこの要件を満たさねばなりません(もちろん、EMCのストレージは大丈夫です)。Oracle社のマニュアルでは、要件を守れないベンダーのスナップショットをつかう場合には、いつもどおり BEGIN / END BACKUP を利用するよう記載されています。

 

Storage Snapshot Optimizationを利用したDBのRecovery

 具体的には、どうやってストレージスナップショットからRECOVERするのでしょうか?大雑把な手順は、以下のとおりです:

  1. スナップショットからリストアする
    • これはクラッシュコンシステントイメージのため、データやREDO、制御ファイル等。通常は、アーカイブログはこのスナップショットには含まれない
  2. 必要なアーカイブログファイルを用意する
    • たとえば、アーカイブログの領域だけ、DBとは別スケジュールでストレージスナップショットを取得しておいても良い
  3. RECOVER DATABASE コマンドでリカバリする

Oracle社のマニュアルは、こちらになります。キモはこの、RECOVER DATABASEコマンドです。

不完全回復をするには、RECOVER DATABASE UNTIL CANCEL SNAPSHOT TIME 'YYYY/MM/DD HH:MI:SS'; のように、スナップショットを作成した時間を "SNAPSHOT TIME" として指定します。

 

Storage Snapshot Optimization を試す!

 では、早速弊社のラボで試してみましょう。XtremIO 上にOracle 12c のDBが作ってあるので、これで実験してみたいと思います。

  • ストレージ:XtremIO
  • データベース:Oracle 12c
  • サーバ:VMware上の仮想マシンで、OSはRHEL
  • その他
    • データベースファイルはすべてRHELのファイルシステム上に作成
    • データベース関連のボリュームは、RDM(物理)で仮想マシンにマウント

という環境です。ただ、ここは普段デモにも使っている環境で、DBが壊れると作り直すのに2日~3日かかるのです(結構デカいDBなんです)。リストアに失敗して万一壊れたら・・・と考え、さらに以下の方針を追加しました

  • リストアと言いつつ、実際にはストレージ・スナップショットを別のRHELにマウントしてそちらでRECOVERする

うん。これで安心。と思うも、さらに、こんなことを考えて、少し気持ちが萎えてきました:

「スナップショットを作るのはXtremIOで簡単にできるけれど、ESXにボリューム見せて、仮想マシンからマウントとか、正直面倒臭い。試したいのはOracleだけなんだけど…」

そうです。エンジニアはみんな面倒くさがりなのです(と自分に言い聞かせる)。面倒くさがりだから、楽をできるように自動化で手間なくできるように、と考えるわけです。

 そこで、はたと気づきました。AppSyncで自動化しちゃえばいいじゃないか(今回は、決してAppSyncの宣伝ではありません(笑))。

というわけで、構成はこんな感じです:

図2.png

では、絵の中にある順番で、早速行ってみたいと思います。

以降の説明では、いろいろコマンドの実行結果や、AppSyncの画面ショットを記載していきます。コマンドについては、ORA-XIO側、およびORA-MNT側双方で実行していきますので、都度説明していきたいと思います。

 

準備:

 ORA-XIOのDBが、実は非アーカイブログモードで実行されていたので、これをアーカイブログモードに変更します。ついでに、LOG_ARCHIVE_DEST_1 を明示的に設定していきます(FRAは今回利用していません)。

ORA-XIO:コマンドは白字で記載しています

[oracle@ora-xio ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on 月 6月 22 18:19:32 2015

 

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

に接続されました。

SQL>

SQL> shutdown immediate;

データベースがクローズされました。

データベースがディスマウントされました。

ORACLEインスタンスがシャットダウンされました。

SQL> startup mount;

ORACLEインスタンスが起動しました。

 

Total System Global Area 4993982464 bytes

Fixed Size                  2691856 bytes

Variable Size            1090522352 bytes

Database Buffers         3892314112 bytes

Redo Buffers                8454144 bytes

データベースがマウントされました。


SQL> alter system set log_archive_dest_1='LOCATION=/u20/oradata/orcl' scope=BOTH;

 

システムが変更されました。


SQL> archive log list;

データベース・ログ・モード     非アーカイブ・モード

自動アーカイブ                 使用禁止

アーカイブ先                    /u20/oradata/orcl

最も古いオンライン・ログ順序   4508

現行のログ順序               4510


SQL> alter database archivelog;

データベースが変更されました。


SQL> alter database open;

データベースが変更されました。

SQL>

SQL> archive log list;

データベース・ログ・モード     アーカイブ・モード

自動アーカイブ                 有効

アーカイブ先                    /u20/oradata/orcl

最も古いオンライン・ログ順序   4508

アーカイブする次のログ順序    4510

現行のログ順序               4510

SQL>

SQL> !ls -la /u20/oradata/orcl

合計 8

drwxr-xr-x. 2 oracle oinstall 4096  2月 10 19:34 2015 .

drwxr-xr-x. 3 oracle oinstall 4096  2月 10 19:34 2015 ..

SQL>

 

DB部分の複製(No Hotbackup)

データや、オンラインREDO等の部分について、クラッシュコンシステントなストレージスナップショットを作成します。ここにはアーカイブログ領域は含まれません(画像は、AppSyncの Bronze プランでDBをクラッシュコンシステントで複製したところ)

WS000347.JPG.jpg

さらに準備

 本番DBを更新して、ログスイッチを実行し、アーカイブログに出力する(あとで、アーカイブログが適用されたことを確かめたいため)。

ORA-XIO:コマンドは白字で記載しています

SQL> insert into scott.dept values (99,'ENGINEER', 'TOKYO');

1行が作成されました。

SQL> set line 100;

SQL> select * from scott.dept;

 

    DEPTNO DNAME                                      LOC

---------- ------------------------------------------ ---------------------------------------

        99 ENGINEER                                   TOKYO     <<<<<<この行を追加

        10 ACCOUNTING                                 NEW YORK

        20 RESEARCH                                   DALLAS

        30 SALES                                      CHICAGO

        40 OPERATIONS                                 BOSTON


SQL> commit;

コミットが完了しました。

SQL> select group#, status from v$log;

 

 

    GROUP# STATUS

---------- ------------------------------------------------

         4 CURRENT

         5 INACTIVE

         6 INACTIVE

 

SQL> alter system switch logfile;

システムが変更されました。


SQL> select group#, status from v$log;

    GROUP# STATUS

---------- ------------------------------------------------

         4 ACTIVE

         5 CURRENT

         6 INACTIVE

 

SQL> !ls -la /u20/oradata/orcl

合計 412500

drwxr-xr-x. 2 oracle oinstall      4096  6月 22 18:50 2015 .

drwxr-xr-x. 3 oracle oinstall      4096  2月 10 19:34 2015 ..

-rw-r-----. 1 oracle oinstall 422387712  6月 22 18:50 2015 1_4510_871328858.dbf

SQL> !date

2015年  6月 22日 月曜日 18:51:12 JST

SQL>

 

アーカイブログの保護

 前のステップで出力したアーカイブログの領域に対して、スナップショットを作成(ここもAppSyncのBRONZEプランで、ファイルシステムの保護を実施します。ここではRHELから見て /u20 の領域を保護します)

WS000350.JPG.jpg

 

保護した領域をマウントする

 DBのクラッシュコンシステントイメージ、および、アーカイブログ領域、両方ともにマウント用のサーバ ORA-MNTにマウントします。ここでは、ファイルシステムとしてオリジナルと同じマウントポイントを指定してマウントします。

●まずは、DB領域をファイルシステムマウント

WS000356.JPG.jpg

●続いて、アーカイブログ領域をマウント。ここももちろんファイルシステムとしてマウントするのみ

WS000362.JPG.jpg

●マウントしてみた結果・・・

ORA-MNT上の操作:コマンドは黄色で表示しています

[oracle@ORA-MNT ~]$ df -k

Filesystem           1K-ブロック    使用   使用可 使用% マウント位置

/dev/mapper/VolGroup-lv_root

                      51606140   8797532  40187168  18% /

tmpfs                  8167948       228   8167720   1% /dev/shm

/dev/sda1               495844     38042    432202   9% /boot

/dev/mapper/VolGroup-lv_home

                      43017424   5593880  35238328  14% /home

/dev/sdf1            309636096   6690032 287217476   3% /u02

/dev/sdd1            1056893108 405479068 597727000  41% /u03

/dev/sde1            1056893108 411385480 591820588  42% /u04

/dev/sdg1            1056893108 419315336 583890732  42% /u05

/dev/sdb1            1056893108 408903304 594302764  41% /u06

/dev/sdh1            103211296   1918624  96049844   2% /u40

/dev/sdc1            103211296   3796952  94171516   4% /u50

/dev/sdi1            103211296    604616  97363852   1% /u20

[oracle@ORA-MNT ~]$

[oracle@ORA-MNT ~]$ ls -la /u20/oradata/orcl

合計 412500

drwxr-xr-x. 2 oracle oinstall      4096  6月 22 18:50 2015 .

drwxr-xr-x. 3 oracle oinstall      4096  2月 10 19:34 2015 ..

-rw-r-----. 1 oracle oinstall 422387712  6月 22 18:50 2015 1_4510_871328858.dbf

 

DBのリカバリーを実施

 ファイルシステムのマウントもできたので、いよいよRECOVER DATABASEを実行してみます。

ORA-MNT上の操作:コマンドは黄色で表示しています

[oracle@ORA-MNT ~]$ env|grep ORA

HOSTNAME=ORA-MNT

ORACLE_SID=orcl

ORACLE_BASE=/u01/app/oracle

ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1

[oracle@ORA-MNT ~]$ sqlplus / as sysdba

 

 

SQL*Plus: Release 12.1.0.1.0 Production on 月 6月 22 19:35:02 2015

 

 

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

 

 

アイドル・インスタンスに接続しました。

 

 

SQL>

SQL> startup mount

ORACLEインスタンスが起動しました。

 

 

Total System Global Area  421724160 bytes

Fixed Size                  2289112 bytes

Variable Size             343933480 bytes

Database Buffers           67108864 bytes

Redo Buffers                8392704 bytes

データベースがマウントされました。

SQL>

SQL> alter system set log_archive_dest_1='LOCATION=/u20/oradata/orcl' scope=BOTH;

 

 

システムが変更されました。

 

 

SQL> RECOVER DATABASE UNTIL CANCEL SNAPSHOT TIME '2015/06/22 18:44:10'; <<<AppSyncでSnapshotを取得した時間を指定

ORA-00279: 変更26247464(06/22/2015 18:42:02で生成)にはスレッド1が必要です ORA-00289:

検討すべきログ・ファイル:/u20/oradata/orcl/1_4510_871328858.dbf ORA-00280:

変更26247464(スレッド1)は順序番号4510に存在します。

 

 

 

 

ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}

<<<ここで空リターンにて、アーカイブログを適用

 

 

ORA-00279: 変更26248858(06/22/2015 18:50:50で生成)にはスレッド1が必要です ORA-00289:

検討すべきログ・ファイル:/u20/oradata/orcl/1_4511_871328858.dbf ORA-00280:

変更26248858(スレッド1)は順序番号4511に存在します。 ORA-00278:

ログ・ファイル'/u20/oradata/orcl/1_4510_871328858.dbf'はこのリカバリでは必要なく

なりました

 

 

 

 

ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}

CANCEL  <<<アーカイブログはもう存在しないので、ここでリカバリ終了

メディア・リカバリが取り消されました。SQL>

SQL>

SQL> ALTER DATABASE OPEN RESETLOGS;

 

 

データベースが変更されました。

 

 

SQL>

SQL> SELECT * FROM SCOTT.DEPT;

 

 

    DEPTNO DNAME                                      LOC

---------- ------------------------------------------ ---------------------------------------

        99 ENGINEER                                   TOKYO <<<アーカイブログが適用されたので、この行が存在する!

        10 ACCOUNTING                                 NEW YORK

        20 RESEARCH                                   DALLAS

        30 SALES                                      CHICAGO

        40 OPERATIONS                                 BOSTON

 

 

SQL>

 

 みなさま、いかがでしょうか? 12c では、RECOVER DATABASEコマンドで、手軽にストレージスナップショットからDBをRECOVERできることがお分かりいただけたかと思います。結構便利です。機会があれば、ぜひお試しいただければと思います。

 

以上

 今日は、EMC Storage Plug-in (以降Plug-in for Oracle Enterprise Manager (以降 EM)のご紹介をしようと思います。あと、ここを読んでくださっている皆さんは、おそらく自分で手を動かす技術者の方も多いと思いますので、ついでにインストールの流れなども…。

 

 

WS000312.JPG.jpgEMC Storage Plug-in って?

 Oracle Enterprise Manager Cloud Control 12c で利用できる、無償のPlug-in です。このPlug-inを導入することにより、EM の画面から、EMCストレージの稼働状況や、構成、性能情報などを確認することができます。また、Oracle DBとストレージの間のマッピング情報なども見ることができます。

 DB管理者がいちいちストレージ管理者に確認しなくても、自分でストレージの状況まで確認できたり、あるいはトラブルシュートの際など、DBのあるファイルが、ストレージのどこにあるのかまで簡単に確認することが可能となります






入手方法

 プラグインは、Oracle社の OEM 12c Extensibility Exchangeページからダウンロードすることが可能です。


インストールの流れ

 詳細は製品マニュアル(英語)に譲りますが、ここでは弊社のSDCに実際に導入した際の画面を眺めつつ、インストールの流れをダイジェストでご紹介していきたいと思います。


前提: 

  • Oracle Enterprise Manager Cloud Controls 12c 環境をご用意ください

本記事執筆時点では、Plug-in のバージョンは 12.1.0.2.0 であり、サポートしているEMのバージョンは 12.1.0.3.0 もしくは 12.1.0.4.0となります。実際に導入の際には ECNこちらページからプロダクトドキュメントを参照の上ご確認ください。

  • Plug-in をご用意ください

Oracle社の OEM 12c Extensibility Exchangeページからダウンロードください。ここではダウンロードした zip をEMのサーバ(今回はRHEL)上にコピーし、その上で unzip しています。


インストールの流れ

・プラグインファイル(*oper)をEMに登録します

 

$ ls -al emc.storage.xplg_12.1.0.2.0.opar

-rwxr--r--. 1 oracle oinstall 99133595 2  5 00:47 2015 emc.storage.xplg_12.1.0.2.0.opar

$ pwd

/home/oracle/kits

$ which emcli

/u01/app/oracle/Middleware/oms/bin/emcli

$ emcli setup -url="https://ora-oem:7804/em" -username=sysman -trustall

Oracle Enterprise Manager Cloud Control 12cリリース3.

Copyright (c) 1996, 2013 Oracle Corporation and/or its affiliates. All rights reserved.

パスワードの入力

Emcliの設定に成功しました

$ emcli import_update -file="/home/oracle/kits/emc.storage.xplg_12.1.0.2.0.opar" -omslocal

Processing update: Plug-in - EMC storage monitoring and management

更新がEnterprise Managerに正常にアップロードされました。自己更新コンソールを使用して、この更新を管理してください。

  黄色い文字のところが、ユーザが入力する部分です。実際にやりたいのは、最後のコマンド "emcli import_update" のところですが、これを実行する前に "emcli -login" するか、もしくは上のサンプルのように "emcli setup" で -trustall でログイン不要な設定にする必要があります。
※ この setup を行う場合、URLで指定するホスト名はFQDNを使わないでください。

管理サーバ(OMS)上に、Plug-inを導入

  • 設定拡張性プラグイン を選択

WS000280.JPG.jpg

 

  • EMC Storageプラグインを選択。  デプロイ→管理サーバー を選択

図1.jpg

 あとは、ウィザードに則って進めます。インストールが全然進まないな?と思ったら、画面右上に画面リフレッシュのアイコンがありますので、クリックしてみてください。


管理エージェント(OMA)側にPlug-inをデプロイ

 今回は、XtremIOに接続している RHELサーバ(ora-xio)Linuxホストエージェントが導入済みです。その上でさらにEMC Storage Plug-inを導入していきます。


  • まずは、設定拡張性プラグイン

図2.png

  • EMC Storageを選択し、デプロイ先→管理エージェントを選択します

図5.png

 

  • デプロイ先を選択します。今回は、XtremIOと接続して利用しているRHEL (ora-xio)を選択します。

図3.jpg

  • 管理エージェントへのデプロイが完了しました

図4.png


監視ターゲットとしてXtremIOを登録

  • 設定ターゲットの追加ターゲットの手動追加 を選択します

図6.png

 

  • 「ターゲット監視プロパティを指定してターゲットを宣言的に追加」を選択。ターゲット・タイプとして「EMC XtremIO Storage」を選択

図7.png

  • 監視エージェントには、先ほど設定した ora-xio を選択。虫眼鏡アイコンをクリックすると、監視エージェントが入ったホストから検索出来ます
  • 入力が完了したら、「手動追加」をクリック

図7.png

  • XtremIOに関する情報を入力します
    • ターゲット名は、あとでEM上表示される名前となります
    • プロパティとして、以下が必須となります
      • XMSホスト名(IP
      • XMS に接続するユーザ名
      • パスワード

図9.png

  • 接続テストがOKであることを確認したら、OKボタンをクリックします

図10.png

これで登録は完了です。


実際にXtremIOの様子を見てみます

  • ターゲット→すべてのターゲット を選択
  • ターゲット画面を下の方にスクロールしていくと、先ほど登録した XtremIO が見えてきます

図11.png

 

  • XtremIO をクリックしてみると、このような画面が現れます
  • まだ性能情報等を収集していないため、空の状態です

図12.png

一日放置しておけば、それなりの性能情報のグラフが出てくるようになります。データの収集間隔はデフォルトで5分となっています。これも設定により変更することが可能です。

 

いかがでしたでしょうか?EMに慣れないうちは割りと煩雑に感じるかもしれませんが、一度設定してしまえば、あとは特に何もする必要はありません。

 

冒頭に書いた、Oracle DBと、ストレージの間のマッピング情報も見たい、という場合には、これとはまた異なる設定が必要となります。

上に書いてきた例だと、登録するターゲットとして "EMC XtremIO Storage" を選択しましたが、ここで "EMC Home" を選択して進んでいくと、XtremIO単体ではなく、DBから一気通貫で見られるようになります。(DBの構成情報などを読み取る関係上、登録には時間がかかりますので、ご注意ください)。

ぜひお試しいただければと思います。

WS000344.JPG.jpg

詳細は、繰り替えご紹介しているNew (and Free!) EMC Storage Plug-in for Oracle Enterprise Manager (OEM) 12cこちらのページから辿って、ドキュメントを参照いただければと思います。


以上

前回からずいぶん時間が空いてしまいました。またまたOracle DBネタで恐縮ですが、今回は、最近引き合いの多いXtremIO Oracle DBを組み合わせた時の話をさせていただきます。


XtremIO とは、言わずと知れた(?)EMC All Flash Array (AFA) のことです。内部的にはFLASHカードを並べて直接制御しているわけではなく、SSDを利用しています。従来のHDDベースのアレイの中身を単にSSDに置き換えたものではなく、All Flashであることを前提としてアーキテクチャをイチから見なおした製品です。個人的には、まさにREDEFINE という言葉にぴったりではないかと思っています。

 Oracle DBとの組み合わせの話に入る前に、簡単にXtremIOの特徴を紹介したいと思います。ここでは詳細情報は他の資料やサイト(http://xtremio.com など)に譲り、さわりだけにしておきます。


●パフォーマンス

  • 常に一貫した、ミリ秒未満のレイテンシーaaa.jpg
    • 非常に高いIOPS処理能力
    • スケールアウトアーキテクチャ
    • 超高速コピー(VMクローンなど)

    ●効率性

    • インライン重複排除
    • シン・プロビジョニング
    • FLASHに特化して設計された、新たなデータ保護

    ●シンプル

    • シンプルで使いやすいGUI
    • 3ステップで完了する、シンプルなボリュームプロビジョニング


    などなど、数多くの特徴があります。個人的には、FLASHの特性を考慮した設計がよくなされていると感じます。

    代表的なものとして、私としては以下の2つを挙げたいと思います:


    FLASHは書き換え回数に上限がある

    XtremIOは、インライン重複排除、すなわちサーバから書き込まれたデータに対して常にリアルタイムに重複排除を実施することにより、FLASHへの書き込み量を減らします。さらに、特定のSSDに書き込みが偏らないように、データがSSD間で均等に分散されるように、アレイ側で考慮しています。つまり、「書かなければその分寿命が伸びる」という理屈です。他社のAll Flash Arrayでも重複排除するものがありますが、実際には一旦フラッシュに書き込んだ後に、後から重複排除する作りになっていたりします。入り口で常に重複排除がONになっていて、「不要なものはFLASHに書かない」ということをきっちり実現しているのは、今現在XtremIOのみとなります。XtremIOは、非常に書き込みの多い本番環境において5年以上利用されたとしても、FLASHの書き換え上限に近づくことが無いことを目標に設計されています。こちらのブログにも、信頼性の話などがまとまっていますので、ぜひ参照ください。

     

    FLASHはランダムアクセスに強い

    →この特性に合わせて、RAIDによるデータ保護の仕組みを見なおしています。従来のHDDはシーケンシャルアクセスに強いため、RAID56ではフルストライプwriteを行っていました。通常はこれでいいのですが、ストレージを使い続けるうちに空き容量が減ってくると、必然的にフルストライプwriteできる連続領域が無くなってきます。このとき、連続領域を確保するために、内部的にデータを移し替える処理、すなわちガベージコレクションが必要となってしまいます。ガベージコレクションが発生すると、ストレージのレスポンスが一時的に悪くなるなど悪影響が出ることが知られています。他社のAll Flash Array でも、従来型のRAIDの仕組みをそのまま踏襲している製品では、残り容量が減ってくるとレスポンスタイムにばらつきが生じたり、性能が悪化したりするものがあります。XtremIOのデータ保護では、FLASHがランダムIOに強いという特性を活かし、ストライプの部分的な更新が可能な作りになっています。つまりガベージコレクションを行なう必要がありません。このため、アレイの空き容量が減ってきた状態でも常に一貫した高い性能を提供し続けることができます。


    この他にも、スケールアウトや高可用性、高性能を実現するために、数多くの面白い特徴がありますが、ここでは紙面の都合で割愛させていただきます。


    Oracle DB XtremIO

     All Flash ArrayであるXtremIO は、前項でも書いたとおり、非常に高速、低レイテンシーです。また、スケールアウトアーキテクチャであるため、システムを構成するノード(X-Brickと呼びます)を追加すると、容量も性能もリニアに向上します。これ以外に、DB管理者の方から見て、メリットとなりそうな項目を挙げてみます。

     

    XtremIOを使う主なメリット


    1.ディスクの物理設計からの解放


    DB管理者の方が、(もしかしたらインフラ管理者の方と一緒に)頭を悩ませているのが、LUNの切り方やRAID構成の選び方など、いわゆる物理設計に絡む部分かもしれません。XtremIOLUNは常にシン・プロビジョニングであり、RAIDの種別などを選択する必要もありません。つまり、必要な個数と容量のLUNを切り出して、サーバに見せればそれでOKというのが、XtremIOです。これだけで All Flash のメリットを享受することができます。十分高速なのでLUNも一個OK!と言いたいところですが、データの領域とログの領域は分けるなど、運用を考えると従来からある指針はある程度守るべきと思います。また、1 LUNだけだとキューがネックになることも考えられますので、高いIOが予測されるような領域、たとえばデータ用のASM DGなどは、目安としては 4個程度のLUNから一つのDGを構成することをおすすめしています。

     

    2.テスト環境が簡単に作成できる

     

    稼働中の業務DBのデータを用いて、テストや開発、検証をしたい、というご要望を良くいただきます。EMCでは、こういったお客様には従来からストレージベースのレプリケーションをご提案してきました。XtremIOが提供するSnapshot を用いると、さらに効率よく柔軟にデータを複製することが可能となります。以下に XtremIOSnapshotの特徴をまとめておきます:

     

    • 瞬時に作成可能
    • 書き込み可能
    • 1つのオリジナルボリュームに対して、最大64個作成可能
    • Snapshot からさらに Snapshotを作り、ツリーとして管理することができる
    • ポインタベースで Redirect on Write の方式
      • そもそもXtremIOの通常のボリューム自体が、重複排除後のブロックを指すポインタとして実装されているため、スナップショットも通常ボリュームも基本的に同じ構造をしている
    • 重複排除されるので、スペースの有効活用が可能
    • 作成、削除、利用時にも性能影響なし

     

    など、もともとある XtremIOの特徴を活かした、柔軟な Snapshot が利用可能となっています。


    余談ですが、AppSyncというソフトウェアが今後 XtremIOに対応する予定です。これを用いると、XtremIO Snapshotがさらに便利に使えるようになります。

    たとえば:

    •  BEGIN BACKUP END BACKUPを実行するなど、Oracle DBと連携してアプリケーション整合性を持った、 XtremIO のスナップショットを簡単に作成できる
    •  作成したスナップショットを、本番以外のサーバにマウントし、必要であれば、自動でDBインスタンスを起動する(DBのリネームなども行う)
    •  設定はすべてGUIで可能。実行もGUIから、あるいは定期的に自動実行ができる

    など、OracleXtremIOを連携させて、簡単にOracle DBの複製を作れる仕組みを提供します。今後にご期待ください。

     

    3. CPUをより効率的に!


    CPUIO waitが多く、CPUサイクルを無駄遣いしているケースがあります。こういった場合に、単純に高速なストレージを利用することにより、CPU使用率を下げることができます。極端な話をすると、CPU使用率が大きく下がれば、コア数まで減らせる可能性がでてきます。

    とえば、AWRで以下のような結果が出るケース。

    fig1.png

    ここでは、大雑把に 41% (14.68+13+8.33+4.96) DB Time が、物理IOにおいて 417msec 余分にかかっている (waitしている)ことを示しています。いわゆるIO集中型ワークロードという感じですが、こういったケースにおいては、高速なストレージをすることによりこれらのwaitを減らせる可能性があります。

     

    もちろん、XtremIOの効果があまり期待できないケースもあります。以下のようなケースでは、DB time のほとんどを DB CPUが占めており、IO wait は出ていません。いわゆる計算集中型のワークロードです。

    fig2.png

    このようなケースでは、ストレージの改善では解決できるものではありません。余談ですが、Wait Class : Concurrency が出ていますので、やはりCPUがもう一杯一杯なのかもしれません。

     

    より詳細については、Wikibon Blog “Virtualization of Oracle Evolves to Best Practice for Production Systemsや、EMCのホワイトペーパー「EMC XTREMIO OPTIMIZED FLASH STORAGE FOR ORACLE DATABASES」で見る事ができますので、興味のある方は、ぜひご参照ください。

     

    考慮点

     Oracle DB XtremIO を利用する場合の考慮点をもう少し考えてみたいと思います。

     

    1.重複排除はOracle DBでも効き目があるのか?

    インライン重複排除が売りのXtremIOですが、Oracle DBに対しても効き目はあるのでしょうか? 結果から書くと、残念ながらあまり効き目はありません。

    御存知の通り、Oracleは、デフォルト 8KBのブロックを持ち、このブロックの中に、データ以外にもいろいろな情報を格納しています。その情報の中には、ブロックごとにユニークな値が含まれています。これが重複排除を妨げる原因の一つとなります。

    ただ、これはXtremIO上にDBが一つだけある場合の話です。

    XtremIO上でDBを複製したり、あるいはXtremIO Snapshot を作成するケースにおいては、DBDBの間の重複排除が十分期待出来ます。

     

    次期バージョンのXtremIO(のOS)では、重複排除に加えて圧縮機能をサポートする予定です。これにより、単一のDBしか利用しないケースにおいても、より効率的にFLASHを利用できるようになります。

     

    2.チューニングは完全に不要なのか?

     

    XtremIOは、一貫して高い性能を誇ります。何も調整しない状態でも、悪くない結果が出ます。しかし、より高い性能を望む場合には、いくらかチューニングするポイントもあります。以降、いくつかのポイントを紹介していきます:


    • REDOのブロックサイズを4KB

     

    XtremIOは、内部的にデータを 4KB ブロック単位で扱います。このため、4KBの整数倍のサイズを持つ Oracle ブロックとの親和性は高く、通常はここのチューニングは必要ありません。しかし、REDOログファイルはちょっと異なります。REDOログのデフォルトのブロックサイズは、512バイトです。このため、4KBの境界に合わないようなIOが発生することになり、そのままだと非効率なIOになることがあります。これを避けるため、REDO ログのブロックサイズを 4KBにすることを推奨しています。

    すでに作成済みのDBに対してこれを行うためには、以下の3ステップの処理が必要となります:

      •  デフォルトブロックサイズを利用しない設定に変更

    例:alter system set "_disk_sector_size_override"=TRUE scope=spfile sid='*';

      •  4KB ブロックサイズの REDOログファイルを必要個数追加する

    例:alter database add logfile thread 1 group 5 ('+XREDO') size 5G blocksize 4096;

      •  ・もともとあった (512バイトブロックの) REDOログを削除する

    My Oracle Support のアカウントをお持ちの方は、サポートドキュメント 1681266.1 (Using 4k Redo Logs on Flash and SSD-based Storage)も合わせてご参照ください。

     

    • DB Write プロセスを多めに

    Oracle社のベストプラクティスだと、DBWRは、CPU 8コアに対して 1 つということが言われますが、EMC社内テストにおいて CPU 1コアに対して 1 DBWRプロセスにすると結果が良くなったケースもあります。すべてのケースに有効とは言えませんが、free buffer waits イベントが多いようなケースにおいては、チューニングの際DBWRの追加を試みる価値はあるかと思います。ちなみに、テストは Oracle 11gR2 にて実施されました。CPUコア数以上にDBWRを増やすとかえって悪い結果となりますので、ご注意ください。

     

    • キューの深さも必要に応じて調整

    キューの深さについても調整すると良い結果が得られることがあります。これについては、海外のBLOG “Getting the Best Oracle performance on XtremIOを紹介したいと思います。

    このBLOG内では、Oracle RAC + ASM on RedHat 6.x FC接続しているという前提で、以下を推奨しています:

     XtremIOにサーバが一台しか接続されていなければ、HBAで許容される最大数(QLogicであれば256Emulexでは128) に設定。1台サーバを追加するたびに、キューの深さを半分に。ただし32より小さくはしない。

    こちらのBLOGでは、他にもいくつかの項目に言及していますので、ぜひ参照頂ければと思います。

     

    • ベンチマークツール”ORION”を使う場合

    蛇足ですが、ストレージの性能を見るために、Oracle社の提供するツールORIONを使われるケースがあるかと思います。御存知の通り、これは単体で動作する、Oracle DBっぽいIOを生成してくれるツールですが、筆者の試した限り、XtremIOではうまく使えないようです。詳細を確認できていませんが、どうやら ORIONはゼロデータをwriteしてくるらしく、XtremIOの重複排除機能が効いてしまうためにちゃんとした性能を見ることができません。

    XtremIOに対して、IOのベンチマークツールを利用する場合、重複排除が常にONになっていることを忘れないでください。すなわち、ランダムデータを書いてくれるようなツールでないと正しい結果が得られなくなってしまいます。


    ■最後に


    All Flash Arrayの評価について、一般的な考慮事項:


    All Flash Arrayの評価をすでにされている、あるいはこれからやろうと考えている方もいらっしゃると思います。Oracle DBと組み合わせる・組み合わせ無いにかかわらず、ぜひ考慮いただきたいのは、現実に則したテストで評価していただきたいということです。たとえば、新品のうちは高速だが、時間がたったら性能が悪くなった、という話も聞いたことがあります。現実的には数年間にわたって利用されるものですので、テストにおいてもアレイの80%以上データで埋めた状態で評価する、とか、ある程度長時間連続でテストするとか、read/writeも現実的な比率で混在させるとか、そういった考慮をしたほうが、より良い評価が行えると考えます。

    All Flash Arrayのテスト方法について、IDCからIDC AFA Performance Testing Frameworkという文書も公開されています。英語ではありますが非常に細かく説明されていますので、評価を実施される際には、ぜひご一読頂ければと思います。

     Oracle 12c が登場してから10ヶ月ほど経過しました。Oracle 11gR220152月からは “Extended Support” 期間に入ることもあり、Oracle 12c を検討されている方もいらっしゃるのではないでしょうか? 新機能もさることながら、新バージョンを検討するにあたって、避けて通れないのが既存のDBの移行でしょう。例えば、既存の11gDB12c に移行する、といったシナリオは、多くのお客様で検討されるものと思います。

    今回は、既存の(12c以前の)DBを、12cのマルチテナント環境に移行する方法について、オラクル社の資料や、EMCのホワイトペーパーをベースにご紹介したいと思います。

     

    Oracle 12cのマルチテナント機能


    Oracle 12c には 500以上の新機能が搭載されているそうですが、中でも目玉といえばやはりマルチテナント機能でしょう。ベースとなるコンテナDBCDB)上に、たくさんのDB(プラガブルDBPDB)をプラグインしていくことにより、ひとつのサーバ上に多数のDBを集約することができます。


    筆者なりにメリットをまとめてみました:

    • サーバのリソース使用量を削減することにより、以前より格段に多くのDBを集約できる(スペック上は、250個程度)
    • DB接続のセッションは、PDB毎に独立で、よそのPDBを覗き見ることはできない
    • PDB毎にリソースの優先度が決められる
    • 多数のPDBをまとめて管理可能
      • 多数のPDBがあっても、パッチ適用は一回でOK
      • RMANですべてのPDBをまとめてバックアップ可能
      • DataGuardですべてのPDBをまとめてコピー可能
    • PDBのひな形から、高速にプロビジョニングが可能

    などなど、数多くのDBの管理に頭を悩ませているDBAの方々にとっては、なかなか集約も悪くないかな、と思わせる内容ではないでしょうか? オラクル社は “Manage Many as One” という言葉で表現していますが、まさに管理面ではこの通りになっているように思います。


    他方、事前にきちんと理解しておくべき点もあるように思います。少し調べてみました:

    • マルチテナントには追加の有償ライセンスが必要
    • 統合されるDBは、すべてバージョンを統一する必要がある
    • SGAやバックグラウンドプロセスはCDBレベルで共有される
    • オンラインRedo、アーカイブログはCDBレベルで共有される
    • UNDO表領域は、CDBに対して一つ
    • 制御ファイル、SPFILEPWDは共有される
    • リソースの優先度設定は、主にCPUに適用される。SGAPGAの使用量の制限まではできない

    いくつかの特徴を挙げてみました。こういった特徴や、コスト、DBの特性、求められるサービスレベル、障害ドメインなども考慮した上で、マルチテナントへの移行については検討されるべきと考えます。


    余談ですが、筆者はマルチテナント・アーキテクチャを初めてみた時に、(細かな違いはあるものの)SQL Server のようだと感じました。CDBがシステムDB、インスタンスで、PDBがユーザDBのようだと…。皆さんの印象はどうでしたか?

     

    ■旧バージョンから、12cマルチテナントへの移行


     考慮すべき点はありますが、条件が合えばマルチテナントは非常に便利な機能であることは間違いないでしょう。DBをオンデマンドで簡単にデプロイするような”DBaaS”のようなことも、これを使えば実現できそうな気がします。個人的には、DBaaSまでいかなくとも、散在したDBをまとめて管理すると言った用途に便利ではないかと思います。


    オラクル社では、12c 以前の既存のDBを、12c のマルチテナント環境に移行するための手順を公開しています。My Oracle Support が利用できる方は、こちらの文書を参照してみてください。Oracle Support Document 1564657.1 (How to migrate an existing pre12c database(nonCDB) to 12c CDB database ?)

    この文書の中では、大きく2つの方法が紹介されています

    1. 空のPDBを作り、そこにDatapump や GoldenGate でデータを移す
    2. 12c以前の既存のDBを12c DB(non-CDB)にアップグレードし、それをさらにPDBとしてプラグインする

    実際にドキュメント内で細かく解説されているのは、2.の方法です。


    この方法を、もう少し現実のシナリオに当てはめて考えてみたいと思います。たとえば、移行のテストを、1回ではなく何回か繰り返す必要が出てくるかもしれません。あるいは、テストした結果問題があったら、元に戻す必要が出てくるかもしれません。

    1. の方法は、何度でも繰り返せるでしょうが、数が増えたりデータ量が増えたりすると、非常に時間がかかる可能性があります。2. の方法は、そもそもデータのコピーを行わないことからあまり時間はかからないように思いますが、既存のDBそのものをアップデートしてしまうので、何度もやり直すには適した方法とは言えません。


    EMCのストレージ技術と組み合わせるとどうでしょう? たとえば2.の移行を、本番DBでいきなり行わずに、ストレージ上で作成した複製に対して実施すればどうでしょう?ストレージ上での複製は非常に高速ですので、何度でも移行のテストを行えますし、何かあっても本番DBは元のままですので即座に元に戻すことができます。

      これについて

    VMAX環境で、TimeFinderを用いた手順が、EMCよりホワイトペーパーとして公開されています。White Paper: Updating Oracle Database 12c with Oracle Multitenant Option (Pluggable Database)

    Oracle12c-multi.png


    図:ストレージの複製技術と組み合わせた、Oracle 12c への移行イメージ

     

     図中ではVMware を用いていますが、Oracleのデータ移行とは直接は関係ありません。EMCのホワイトペーパーの内容に合わせて記載しています。Oracle DBを仮想化することによるメリットも多数ありますが、それはまた別の機会に。

     

     VMAXを使っていないとしても、手順については様々な環境において参考になるかと思います。ぜひ活用ください

    ストレージでバックアップできるのはわかった。ところでASMを使うときの注意点をもう少し教えてくれないか?と聞かれることがあります。今回は、前回「Oracleデータベースのストレージベースバックアップ:基礎」の続きで、ASMについて書きたいと思います。

     

    ASMBLOCKストレージ、およびNFSの両方で利用できますが、ここではまず BLOCKを前提に書きたいと思います。私が日本で会う顧客のほとんどは、BLOCKストレージでASMを利用しています。NFSASMを利用している顧客は1社しか知りません。皆さんの扱っているシステムではどうでしょう?

     

    ASM DGのコピーを業務サーバにマウントする時は、ASM DG rename してください

     以前のOracle DBでは、ひとつのDBサーバに複数のASMインスタンスを起動できました。これを利用して、ASM DGコピーを業務サーバにマウントするときに、新たにASMインスタンスを起動することにより、同じ名前のASM DGを使用することが可能でした。しかし、新しいバージョンのOracle、たとえばOracle11gR2 では、ひとつのサーバにひとつのASMインスタンスしか起動できなくなっています。このため、コピーしたASM DGを業務サーバにマウントするときには、ASM DG Rename する必要があります。 EMC Replication Manager を用いることにより、このRenameの処理を自動化することができます。


    ASM DGの中では整合性を保つこと

     ASMの一つのDGが複数のLUNから構成されている場合でも、そのDGを複製する際には、DG内で整合性を保つ必要があります。ASMでは、DGに関するメタ情報も同じDG内に保持しているようです。このため、例えばリバランシングが発生するような状況を考えると、たとえ hot backup mode を使用していたとしても、少なくともASM DGの単位では書き込み順を崩さないことが必要です。EMCのストレージでは、複数のLUNを論理的にグルーピングすることにより、そのグループ内で整合性を保つことができます。これは、ハイエンドは当然ですが、ミッドレンジストレージ、あるいはRecoverPointを用いても同じことが可能です。

     

    ASMの障害グループ(Failure Groups を使う時は注意が必要

     ASMを使用して、ストレージ筐体の間でデータをミラーリングしたい、という要望をもらうことがあります。この場合、ASMの障害グループ(Failure Groups)を用いて、ストレージ間でデータを分散することになります。図では、ひとつのASM-DG#1が、2つの障害グループ に分散している様子を描いています。


    ASMFailureGroups.png

     障害グループを用いたASMミラーリングの構成自体は、ストレージの特別な機能を利用するものではありません。

    さて、この構成で、ASM-DG#1 をストレージで複製したいとき、どうしたらよいでしょうか?

    実は、オラクル社がサポートするのは、ASM-DG#1全体について、整合性を持った複製を取得している場合だけになります。

    つまり一方の障害グループの複製をとっただけでは不十分、ということになります。


    障害のシナリオについて考えてみます:


    1)障害グループのうち1つが破損した

    この場合、生き残った障害グループから、ASMが破損したグループを復旧します。つまり、せっかくストレージで取得した複製は利用することがありません


    2)障害グループ2つのうち、2つとも破損した

    (ほとんどそんなことは起こらないと思いますが)ストレージの機能で1つの障害グループをリストアしたとしても、Oracle DBが復旧できるかどうかを、オラクル社は正式には保証していません。オラクル社は、すべての障害グループ(図の中では、2つの障害グループ)をきちんとリストアした時のみ、Oracle DBが復旧できることを保証しています。図の中で言うと、Replicas#1 Replicas#2 の両方の複製を日々取得している必要があります。ただし、その場合でも、Replicas#1 Replicas#2 が同じタイミングで整合性をもって取得されている必要があります。障害グループが別なストレージに配置される場合においては、これを行うのは非常に難しくなります。

     

    一言で言うと、複数ある障害グループのうち、一つだけを複製してもだめ、と言えます。これは、災害対策を行う際のリモートレプリケーションでも同じことが言えます。

     

    お客様が障害グループを使いたいという背景には、実はストレージの筐体自体を冗長化して、より可用性を高めたいという要望があることが多いと感じます。この場合には、ストレージの機能で筐体間ミラーを行う、あるいは、現在であれば、VPLEXを用いるとよりスマートな構成ができるように思います

     

     今回は、ASMの扱いについて少し細かく書いてみました。

    今後も、日々お客様との会話の中で気づいたことをBLOGとして書いていきたいと思います。

      EMC JapanSEとして8年以上働いていますが、今でもストレージベースのバックアップを特別なものと考えるお客様に出会うことがあります。

    Oracle データベース のバックアップをストレージで行えるのか?それは何か特殊で特別なことではないのか?という印象を持たれている気がします。

    そんなとき、私はお客様とこんな会話をしています。非常に基本的な内容だと思いますが、自分の頭のなかを整理する意味でも、ここにまとめてみます。

     

    ・ストレージベースのバックアップとは?

     ストレージアレイの中で、データのポイントイン・タイム・コピーを取得します。物理コピーである Cloneを取得したり、論理コピーである Snapshot を取得することも可能です。Cloneの場合、RAID-1 のミラーボリュームを動的につけたり離したりするようなイメージ、と捉えるとわかりやすいかもしれません。ここでは深く触れませんが、CloneSnapshot もそれぞれ用途ごとに使い分けたり、Cloneからさらに Snapshot を取得するといった、組み合わせを行うこともあります。

    処理が高速である、サーバやネットワークのリソースを消費しない、といったバックアップとしての利点だけでなく、テスト・開発・QAなど別の用途にもデータを高速に再利用できるといった、多くの利点があります(これを、Re-purposing と呼ぶこともあります)。

     

    ・オンラインバックアップが取得できるのか?

     もちろん可能です。Oracleをオフラインにしたあとに、ストレージアレイの中でコピーを取得することもできますが、Oracleがオンラインの状態でもコピーを取得することが可能です。

     

    Oracleの「正式な」バックアップがとれるのか?

     Oracle Database のオンラインバックアップには、大きく2種類あります:

        1)ユーザ管理のバックアップ(User Managed Badkup

           2) RMANによるバックアップ

     

     ストレージベースのバックアップは、この2つのうち「ユーザ管理のバックアップ」と組み合わせることになります。

    ユーザ管理のバックアップの一般的な手順と、サンプルコマンドは以下のとおりです:

    1. BEGIN hot-backup.

         SQL > ALTER DATABASE BEGIN BACKUP;

    2.Copy data files

    3.END hot-backup

         SQL > ALTER DATABASE END BACKUP;

    4.Archive current Redo Log

         SQL > ALTER SYSTEM ARCHIVE LOG CURRENT;

    5.Copy the latest archive log for recovery

    6.Backup control files

         SQL > ALTER DATABASE BACKUP CONTROLFILE TO TRACE;  (text format)

         SQL > ALTER DATABASE BACKUP CONTROLFILE TO 'XXX'; (binary format)

     

     筆者は、Oracle 7 の時代からこのバックアップ方法を使用してきました。ただし、その頃は、step 2 の部分ではOSのコピーコマンド等を使用していました。ストレージベースのバックアップにおいてもこの手順は何も変わりません。つまり、「Oracle databaseのバックアップ」としての手順はごく一般的なものです。ただし、一つだけ違うのは、step 2 の部分でストレージアレイ内のコピー機能を使用することです。ここが大きな違いです。OSのコピーコマンドでは長時間かかるような、大きなサイズのデータベースのバックアップでも、ストレージのコピー機能を用いれば瞬時に完了します。

     この一連の処理はスクリプトを作成しても実行可能ですが、これらを自動化するツールとして、EMC Replication Manager という製品を提供しています。この製品を用いると、スクリプトを作成すること無く、GUIから設定を行うだけで自動的に上記のステップを実行することができます。さらにバックアップからのリストアや、他のホストへデータベースのコピーをマウントするなど、およそ必要となる機能が自動化されています。

    Replication ManagerによるOracle Databaseのバックアップに関する詳細は、White Paper: EMC Replication Manager Integration with Oracle Database Server — A Detailed Reviewを参照ください。

     

    RACASMを使っていても大丈夫か?

    Oracleの一般的なバックアップ手順をそのまま使用するだけなので、もちろん大丈夫です(Replication Manager を使っても、もちろん大丈夫です)。

     

    ・他にもっと便利な機能はあるか?

     ストレージの持つ複製機能を用いると、Oracle Database を更に活用することができます。以下に幾つかその例をあげます。


    1) Hot backup mode を使わないコピー

    データベースの数が多くなると、いちいち hot backup にするのも手間がかかります。また、開発・テスト・QA 環境用にコピーを作成する場合は、いちいちhot backupモードを用いずに簡単にコピーできることが望まれます。

    My Oracle Support article 604683.1 Supported Backup, Restore and Recovery Operations using Third Party Snapshot Technologies の条件や手順を守れば、hot backup を使わずに簡単にOracle Database のコピーを作成することができます。

    また、Oracle 12c で導入された Storage Snapshot Optimization を利用すれば、hot backup を使わずに取得した Oracle Database のコピーに対して、従来より簡単に(コマンド一つで)Roll forward することができます。

     

    2)災害対策

    ストレージの持つリモート複製機能を用いれば、Oracle Database を遠隔地に簡単にコピーすることが可能です。ここでは深く触れませんが、複数のOracleインスタンスを同時にコピーする、Oracle Database とその他のデータを同時にコピーする、など、Oracle DataGuardを適用するのが難しい場合にも適用が可能です。

    最後にストレージベースのバックアップのイメージ図を掲載します。ステップごとに考慮すべきポイントがあります。

    WS000165.JPG.jpg

     バックアップについて、私のお会いするお客様の多くが、皆さん悩みを抱えていました。特に大規模であったり、24時間365日止められないミッションクリティカルな環境であったり、最近だと仮想化した後のバックアップで困っていたり…。EMCソリューションが少しでも役に立つように、私も日々勉強しています。

     今後も、日々お客様との会話の中で気づいたことをBLOGとして書いていきたいと思います。

    Filter Blog

    By date:
    By tag: