つまり、共有ストレージの容量不足に関する課題を放置すると、負のスパイラルを招く恐れがあります。

1. 共有ストレージが不足する。
2. ユーザは個人に割り当てられたストレージ領域を使う。
3. 個々のユーザのストレージに、共有データが保存される。
4. 個人のストレージ容量が不足する。
5. ストレージ全体の利用効率が低下する。
6. 共有データを使った協業効率が低下する。
7. バックアップストレージの使用量が増える。

　この様な課題に対し、HPE SimpliVityは有効な解決方法を提供できます。解決方法をまとめた資料を以下よりダウンロードできます。本課題に直面されている管理者の一助になれば幸いです。

2. バックアップ運用に関する課題

　基盤管理者の方であれば、1度は上記のような場面に遭遇したことがあるのではないかと思います。
　バックアップは個人の責任という一面もありますが、だからといって、個人対応のみに任せるといったことは許されません。個人に任せてしまうと、バックアップデータをストレージのあちこちに保存されてしまい、ストレージが余計に消費されてしまう恐れがあります。そもそもシステム障害に対しては、基盤管理者が責任をもってバックアップを取得する必要があります。万が一、基盤管理者がバックアップの取得を怠っていた際にシステム障害が発生した場合、基盤管理者にはユーザからの「悲痛な叫び」と共に上司からの「叱責」が重くのしかかります。このような最悪の事態を避けるために、基盤管理者はしっかりとしたバックアップシステムの構築、運用をする必要があります。

　バックアップシステムを検討する際は、単に基盤管理者側の都合だけではなく、ユーザ側の要望を加味した上で、ユーザにとって有益で安心できる仕組みを考える必要があります。このようなバックアップシステムを構築する上の検討すべきポイントは下記になります。

• バックアップの頻度（日毎、週毎、月毎、、、）
• バックアップの目的（システムバックアップ、データバックアップ）
• バックアップの種類（フルバックアップ 、差分バックアップ、スナップショット）
• 保管世代・期間
• バックアップ・リストアの単位（仮想マシン単位、LUN単位、、）
• バックアップデータの保管場所（同一サーバ内、同一センタ内、別センタ）
• RPO(Recovery Point Objective),RTO(Recovery Time Objective)

図 2. バックアップ運用のポイント

　上記に挙げた検討ポイントとユーザの復旧要望や利便性を加味した上でバックアップシステムを整備できれば理想的ではありますが、コストや運用負荷の兼ね合いから妥協せざるを得ない場合も多く、システム構築後に以下の様な課題が残ります。

その① バックアップの取得間隔が長く、ユーザが要望する復旧ポイント でリカバリできない

　バックアップの取得間隔が短ければ短いほど、ユーザのリカバリ要求を満たせます。しかし、実際にはストレージの容量の問題やバックアップ時のI/O負荷の点より、頻繁にはバックアップを取得できません。1週間に一度、休日夜間にのみバックアップを取得している環境も少なくありません。バックアップ間隔が週1回の場合、リストアできる復旧ポイント は最長で、約1週間前ということになってしまいます。

その② リストア単位 がユーザの復旧要望にあわない

　例えば、ユーザが誤ってデータを削除してしまった場合、ユーザは削除したファイルのみのリストアを希望します。しかし、システムの仕様により、フォルダ単位でのリカバリしかできないといったことがあります。この場合、ユーザはリカバリに対象外のファイルを一時的に退避させる必要があり、非常に面倒な作業が発生します。

その③ バックアップやリストアを実施できる時間帯が限られる

　バックアップを実行するとシステム性能の低下により業務に影響がでてしまう為、業務時間には実行できないという制約が生じます。よって、バックアップの実施時間を夜間や休日に実施することが一般的です。ただし、24時間稼働するオンラインサービスを支えるシステム等では、バックアップを実施する時間帯の調整が難しくなってきています。
上記のような事情を配慮し、ストレージ容量や時間を節約する為の差分バックアップといった手法も考えられますが、バックアップを取得する際の負荷や時間を削減できる反面、リストア時の負荷が高まり、リストアを実施する時間帯に制約が生じます。

その④ BCP対策としてDRサイトを構築したいが、リソースやノウハウが無い

　単にテープバックアップを別サイトに送るだけといったBCP対策は、不十分なケースが多々あります。有事の際、いち早くサービスを再開する為には、下記のポイントを検討する必要があります。

• DRサイトへ常に最新のバックアップデータを送る
• 被災地側にもサーバリソースを配置する
• 最新のバックアップデータを使ってサービスを再開させる仕組みを整える

図 3. バックアップの運用課題

　上記に挙げた課題に対し、HPE SimpliVityは有効な解決方法を提供できます。解決方法をまとめた資料を以下よりダウンロードできます。本課題に直面されている管理者の一助になれば幸いです。

3. VDIの運用に関する課題

　VDI環境を設計する際、下記の何れかより仮想デスクトップの展開方式を検討します。

• リンククローン方式
• フルクローン方式

　一般的にVDI環境では大規模であればあるほど、ストレージ容量を削減する目的で”リンククローン方式“を採用する傾向にあります。

図 4. リンククローン・フルクローンの概要

　それぞれの展開方式のデメリットについて簡単に記述します。

① リンククローン方式のデメリット

　リンククローン方式を採用する主な目的は下記になります。

• ユーザ環境の統一管理
• ストレージの消費量の削減

　VDI のユーザ環境を統一的に管理できる点については、管理面にとってはメリットといえますが、利用者からするとストレスの要因になる場合があり、これがデメリットに転じることがあります。ユーザ環境に対して柔軟性を求める利用者は、自分の業務に適した環境設定を希望します。例えば、 アプリケーションのインストールを自由に行いたいと考えるでしょう。仮に利用者が「ユーザ環境の統一管理」に不満を抱いてしまうと、利用者は VDI 環境の受け入れに難色を示します。最悪の場合、管理者は VDI 環境とは別に個別環境を準備する破目になるというわけです。

② フルクローン方式のデメリット

　フルクローン環境の場合、必要となるストレージ容量が増える為、VDI環境のように仮想マシンが多い環境なると、頻繁にバックアップを取ることが難しくなります。そのため、“バックアップ運用で課題”にしたような“ユーザが望む復旧ポイントのリカバリができない”という課題が顕著になります。また、個別にアプリを入れられる環境となることから、ウイルス感染などのセキュリティリスクが高くなることから、より強固なセキュリティ対策が必要になります。