ワイヴァンアイエス研究所ブログ

ストレージシステムやITの技術動向やテクノロジーなどを紹介。その他、趣味的な話題もあります

VMに適切な重複排除バックアップストレージの条件

堅い話が続いて大変すみません!

現在ではバックアップする対象はデータだけではなく、VM(仮想マシン)そのものが対象になることが多くなっています。


VMでシステムを構築している場合には、その環境を重複排除ストレージにバックアップすると重複排除率が高く効果的ということは良く知られています。そのため、バックアップ先のストレージとして、ターゲット型重複排除ストレージが多くの場で使われています。


通常、バックアップしてあるVMを復旧するには

  1. 故障したプライマリーストレージを復旧
  2. 重複排除バックアップストレージからプライマリーストレージからリストア

という作業となります。


上記の1および、特に2ですが、他のトピックで説明しましたようにインライン重複排除バックアップからのリストア処理には時間がかかります。リストアが遅いとそれだけ業務停止時間が長くなりビジネスへの影響が大きくなります。


ところで、バックアップアプリケーションによっては、バックアップイメージファイルからリストアなどの作業を行わずに、バックアップしたストレージからVMを起動できる機能を持っています。『バックアップストレージから直接VMを起動できる』(即時的なVMリカバリー)機能があれば、上記の1と2の作業完了を待たなくとも(暫定的なVMとして)業務を数分で再開でき業務の停止時間を最小限に抑えられます。とても有効な機能です。


しかし、アプリケーション側にそのような機能があっても、インライン重複排除バックアップ装置からVMを起動するときには、重複排除されたVMの状態からRehydrate(再水和、再構成)してもとのVMイメージに戻すのに長時間(数時間)かかってしまいますので、せっかくのバックアップアプリの即時的なVMリカバリー機能が全く生かせないことになります。


VMのバックアップに重複排除バックアップ装置は大変に効果があることは確かです。さらにリストアが短時間に済めば、もっと効果的です。バックアップの策定には必ずリストアを含めて考えると良いですね。


参考サイト:

  • 重複排除バックアップの高速リストアについて(ExaGrid
  • バックアップアプリのVM即時起動について(Veeam Instant VM Recovery



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年02月25日 12:20 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

重複排除バックアップストレージの意外な盲点

少々専門的な内容です。

エンタープライズ系のバックアップでは、ターゲット型の重複排除ストレージが多く採用されていて、市場での実質的なスタンダードとなっています。それらの製品群では、CPUの高速化や搭載メモリの大容量化そして処理の進化などが進み、重複排除を「インライン」で処理することが常識化してしまっています。そこに疑問を投げかける人はまずいないようです。


バックアップで大容量のデータ容量が大幅に縮小されバックアップ速度もまずまず高速だから、何が問題なのか?』という質問は当然です。


故障に関することではありません。一言でいうと、『リストアスピードが遅い』のです。


インライン重複排除ストレージの本質的な仕組みのため、現在の装置ではリストアの速度はバックアップ時の速度の「数分の1」になります。多分、この実態を知らないで導入していることは多いと思います。バックアップはリストアとセットで考えるべきなのですが、リストア時の事態が想定されていないことが多そうです。装置メーカー側もこのことを話題にはしませんし。


バックアップ時間を8時間で済むように装置を選定した場合、例えばリストア速度がバックアップ速度の「5分の1」に遅くなると、データのリストアには40時間(約1.7日)かかることになってしまいます。これでは、あまりよいバックアップ装置とは言えません。


(なぜ、リストア速度がバックアップ速度よりもかなり遅くなるかの原因は、このトピックの最後に説明しますが、ちょっと面倒な内容なので飛ばしても構いません。)


リストア速度はバックアップ速度よりもかなり遅くなることを考えずにバックアップの設計を進めてはいけないことを意識すべきです。


ターゲット型重複排除ストレージを調べてみると、その中にもリストアがバックアップ速度と変わらない(遅くならない)製品もありました。しかし日本ではその道の専門家にもあまり知られていません。


例えば、ExaGridという製品ですが、これはインラインとは異なる「Adaptive」型というアーキテクチャを採用してます。その結果、インライン同等のバックアップ速度を実現しながら、リストアもバックアップと同じ速度を実現しているようです。「ポストプロセス」という古いアーキテクチャとは異なっているユニークな製品ですね。内容を調べてみたら、意外と面白い製品でした。リストアも高速というのが、役に立つバックアップといえると思います。


(以下の説明は、あまり正確性を追求しておりませんがご参考まで)

インライン処理では、データをストレージに格納する前に重複排除を行う。バックアップサーバーから送られてきた大量のデータを受ける側(ターゲット型重複排除装置)が自身の内部のストレージ(主にHDD)に保存する前に重複排除処理を行う。そうすると、バックアップ装置に保存されるデータのすべては重複排除された形式(元のデータとは全く異なるそれぞれがユニークな小片の集まり)となる。これをそのまま元の装置(主にプライマリーストレージ)に戻しても使えない。本来の元のデータに戻すため(リストア)には、『rehydrate』、直訳では再水和、という大量の小片群から必要なものを引っ張り出して元のデータ形式に戻すコンピューティング集中型の処理が必要になる。これがリストアで時間が長くかかる原因となる。

データの重複排除というのは、部品と設計図に展開する作業に例えるとイメージしやすいかと思う。バックアップ時には、元のデータ(製品に相当)を重複しないユニークな部品に分解して、その部品がどの場所に使われているかを設計図とする。リストア時には、この設計図をもとにしてばらばらの部品群から必要な部品を見つけ出してもとの製品を組み立てる作業に似ている。これがとてもとても時間がかかる処理になる。



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年02月18日 07:40 ] カテゴリ:バックアップ/リストア | TB(0) | CM(0)

世界データ生成量

昨日(2020.02.05)に、イベント「IDC Storage Vision Japan 2020」が開催されたので、聴講してきました。専門分野の業界動向や技術動向を把握するために、毎年欠かさず参加しています。


メーカーが主催するセミナーとは異なり、今後台頭するであろう新しい技術を知るために大変役に立ちます。単なる製品紹介ではないところがいいのです。


セミナーの一つで語られた「世界データ生成量予測」を紹介します。


  • 2023年のデータ生成量は『103 ZB(ゼタバイト)』に拡大(2018年と比較するとその3.2倍)
  • 2018年から2023年のCAGR(Compouned Average Growth Rate:年平均成長率)は、25.8%

このことから、各1年ごとの世界のデータ生成量を計算すると(大まかに丸めています)


  • 2018年: 32 ZB
  • 2019年: 41 ZB
  • 2020年: 51 ZB
  • 2021年: 65 ZB
  • 2022年: 81 ZB
  • 2023年:103 ZB

というように増加していくことになります。その後もCAGRが25.8%で推移すると、『2025年には全世界のデジタルデータの生成量が163ゼタバイトに達する』という記事(2018.05.16)につながっていくんですね。



すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックいただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年02月06日 21:48 ] カテゴリ:ITインフラ | TB(0) | CM(0)

CentOS 8 (CUI環境)の画面を一定時間後に消灯するメモ

sambaを導入したCentOS 8 (CUI環境)の画面を一定時間後にblank(暗く)する方法をメモとして残します。


旧型ラップトップコンピューター(いわゆるノートPC)Panasonic Let's Note CF-N8に、CentOS 8をインストールしsambaを導入しました。旧型PCの能力がGUI環境を導入するには非力なこともあり、基本的なファイルサーバーとしてだけ使うので、CUI環境を構築しました。インストールとsambaの設定は問題なく完了し、ファイルサーバーとして機能しています。


一つだけ困ったのは、ノートPCの液晶画面が、いつまでも点灯したままの状態です。このままでは、液晶スクリーンに焼き付きが発生します。コンソールを一定時間操作しないときに、スクリーンを消灯させたいのです。


画面が消灯するまでの時間(秒単位)は、 /sys/module/kernel/parameters/consoleblank に記述されています。内容を見ると「0」が入っていました。「0」はdisable blankingで消灯しない設定になっています。


consoleblank 内の値を書き換えるのは、「setterm」コマンドになります。(以下、コマンドの説明の行頭「#」は、rootのプロンプトを示します)


# setterm -blank 2


のように、「分」単位で値を定義します。上記の例では、コンソール操作が何もないと2分後に画面が消灯します。上記のコマンドの後に、/sys/module/kernel/parameters/consoleblank の値を調べると「120」になっています。2分=120秒の「120」が書き込まれています。しかし、CentOS 8を再起動すると、「0」にリセットされます。


毎回の起動ごとにログインしてコマンドを入力すれば希望の時間後に画面が消灯できます。しかし、起動した後、ログインしてコマンドを入力するのは面倒です。ログインせず、PCが起動した後、自動的に一定時間に画面を消灯させたいのです。少し大げさになりますが、サービスの作成を試行錯誤した結果を紹介します。今回の例とは逆に、消灯させたくないという場合にも応用できます。


ノートPCの画面(CUI環境)で端末名を調べる

コマンドで


# tty


の出力結果(端末名)を記録しておきます。ここでは、「/dev/tty1」でした。


起動スクリプトを作成

myconsoleblank.shという名前で作成しましたが場所も重要でした。rootのホームディレクトリ「/root」の下に作成してもエラーで実行できませんでした(『Permission denied』のようなエラー、詳しい内容は忘れました、すみません。chmod +x でもダメでした)。そこで /usr/local/bin/ に作成しました。スクリプトの内容は以下です。消灯する時間は以下の例では、1分にしています。適宜、ご希望の「分」数を使ってください。myconsoleblank.sh の内容は以下です。


#!/bin/bash
#Called by /etc/systemd/system/my-console-blank-enable.service
#Turn the console terminal Off 1 minutes later
/bin/setterm -blank 1 > /dev/tty1


このスクリプトに実行権限を付与します。


# chmod 755 /usr/local/bin/myconsoleblank.sh


サービス定義を登録

/etc/systemd/system/ に、my-console-blank-enable.service の名前で以下の内容を作成します。(注:Description の行は、myconsoleblank.sh まで途中で改行せずに1行にしてください)


[Unit]
Description = Turn the console terminal Off after a time defined by myconsoleblank.sh

[Service]
Type = simple
User = root

RemainAfterExit = yes
EnvironmentFile = /etc/sysconfig/rootenv
ExecStart = /usr/local/bin/myconsoleblank.sh
Restart = always

[Install]
WantedBy = multi-user.target


EnvironmentFile を作成

/etc/sysconfig/ にスクリプト実行時の環境変数を設定します。rootenv という名前で作成しました。


HOME=/root
TERM=linux
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin


PATH などの値は、コマンド printenv などで調べられます。


サービスを起動

以下のコマンドを入力します。


# systemctl start my-console-blank-enable


状態を確認するのは、以下のコマンド。


# systemctl status my-console-blank-enable


エラーがなかったら、自動起動にします。


# systemctl enable my-console-blank-enable


エラーが出たら、例えば以下のようにして調べてください。


# journalctl -b | grep myconsoleblank


他には、ブート時に実行されるコマンドラインを編集して「consoleblank=x」で制御する方法があります(xは秒数で、0はdisable blanking)。こちらは試しておりませんが、以下のサイトをご覧ください。


参考URL: How do I disable the blank console “screensaver” on Ubuntu Server?


以上です。


すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。


以下のバナーをクリックしていただくと、とても励みになります!

にほんブログ村 IT技術ブログ IT技術情報へ

[Ctrl]キーを押しながらクリックすると他のページに飛びません

[ 2020年02月02日 09:00 ] カテゴリ:linux | TB(0) | CM(0)