こんにちは。

最近は、IT Pro エバンジェリスト 奥主 が開発系の話をよく書いてくれているので、私も対抗して「管理系」の話をしたいと思います。(03/13 の無償イベントでも、エンタープライズ検索の Ranking チューニングなど、管理ノウハウの話をする予定です。)
タイトルが NHK の番組のようになってしまいましたので、そのまま NHK の解説風味で進めていきましょう。

さて、みなさんは、SharePoint の管理を普段どのように実施されておられますか ? 将来的には、こうした現場の管理ノウハウなどの情報共有ができていくと良いですが、今日は、その足がかりとして概念や考え方のみをざっくりと解説したいと思います。(今さらの情報ばかりですが、改めて整理してみてみましょう)

バックアップ / リストア (事故・病気への備え)

まず基本となるバックアップ / リストアですが、このバックアップ / リストアに限らず、「SharePoint の管理」といった場合には、

• サーバー管理
• サイト管理

という 2 つの視点があることをおぼえておきましょう。無論、細かなことを言えば、「サイトコレクション」なども管理の対象ですが、ここで説明したいのはそうした細かな話ではありません。

例えば、「社内の開発プロジェクト用の SharePoint (ファーム)」 などを構成し、このファームの中に、「A プロジェクト管理サイト」、「B 開発チームポータルサイト」など、プロジェクトごとの複数のサイトコレクションやサイトを構成するといった使用方法は、現場ではごく一般的におこなわれていることでしょう。
この場合、あるサイト X に問題が発生し、何日か前にリストアしたいという場合に、もしサーバー単位のバックアップ / リストアのみしか実施できなければ、この「プロジェクト X」のために社内のすべてのプロジェクトのサイトを数日前にリストアするといった有り得ない運用を強いられることになるでしょう。(なぜなら、これらのサイトはすべて同じ SharePoint のサーバー上に乗っており、同じデータベースを使用しているからです)

こうした場合に、サイト単位での管理をおこなえるツールが、SharePoint Designer 2007 です。このツールは、開発者たちの間では Visual Studio よりも安価な現場レベルでの簡易カスタマイズのツールとして知られていますが、「管理」という側面では、こうしたサイトレベルの管理ツールとして活躍します。”サーバー” ではなく、各現場部門での “サイト” の管理者は、サーバーマシンにログインするなどの面倒な手続きではなく SharePoint Designer を使って自席からリモートで接続をおこなうことで、自分が立てたサイトのバックアップと、事故発生時などのリストア (リカバリー) をおこなうことができます (※1)。
SharePoint Designer を使用したバックアップ/復元の具体的手順についてはここでは詳述しませんが、下記に記載されていますので参考にしてください。(ただし、この中に書かれている 3 種類のアプローチのうち、.fwp と .stp は「バックアップ/復元」のためのものではなく、PDCA サイクル (業務改善) などで実行済のサイトをひな形に新しいサイトを構成するための仕組みです。)

http://office.microsoft.com/ja-jp/sharepointdesigner/HA100819231041.aspx

どのサイトをどの頻度でバックアップすべきかはサイト管理者でなければ判断できないはずです。事故発生時に全部の責任を「サーバー管理者」に押し付けられないよう、サーバー管理者の方は、普段から「サイト管理者」にも自主的なバックアップを呼びかけておくと良いでしょう。

一方、”サーバー管理” のためのバックアップは、ごく一般のサーバーアプリケーションでおこなわれている IT Pro の作業と同じです。SharePoint では、stsadm.exe というサーバーマシン上で使用可能なコマンドを使って SharePoint Server のバックアップ / 復元をおこなうことができるようになっています。
ただし、この stsadm.exe によるバックアップ / リストアは、VSS (ボリュームシャドウコピー) などのテクノロジーを使用したものではありません。サーバーへの負荷も大きく、(リストアなどでは) 長時間の停止が必要など、さまざまな観点 (他にもディザスタリカバリーの観点など) で、いわゆる停止時間やデータの消失が企業の経営・運営を直撃するようなミッションクリティカルな領域や、データ量が大きなケースなどには向かないという点も憶えておいてください。

こうしたケースにおけるサーバー管理では、SharePoint が持っている SQL Server のデータベースや、ディスク上のアプリケーションファイルそのものを対象にバックアップ / 復元をします。Microsoft では、SharePoint のこうしたミッションクリティカルなバックアップソリューションについてはSCDPM (System Center Data Protection Manager) を使用することを強く推奨しています。また、専用のサードパーティによるバックアップソリューション製品など (AvePoint, Commvault, など) も選択肢となってくるでしょう。
他のアプリケーション製品 (データベース含む) や OS なども含めた統一的バックアップも視野に、適切な製品ソリューション (日本のベンダーが提供しているものも含め) を選択すると良いでしょう。

データ量やトランザクションの増加 (老後への備え)

SharePoint では、シナリオによって想定されているデータ量、スケーラビリティなどに相違があるので注意してください。

例えば、SharePoint の Web アプリケーションについては、ご存じの通り Web ファームの負荷分散 (ロードバランス) や、データベースにおいてはスナップショットやミラー化も可能で (※2)、こうした実績も数多く存在しています。(Microsoft 社内でも、大量のサイトを持ったアジア専用サイト、本社専用サイトなどが実際に運営されています。) また、書籍「VSTO と SharePoint Server 2007 による開発技術」(第 8 章) で述べているように、エンタープライズ検索では、クエリサーバーの負荷分散やデータベースのクラスタなどを組み合わせて、大量のコンテンツソースやインデックスを扱う検索ポータルを提供し、さまざまなチューニングをおこなうことができます。(実際、Microsoft 社内でも多数のクラスタを立てて運用されています。)

しかし、単一のサイトや、単一のリストについてはこの限りではありません。データのパーティション化やパーティションパラレル化などは、今や一般の RDBMS では当たり前の管理技術かもしれませんが、SharePoint のリストはこうした大量データを扱った管理のための仕組みは備わっていません。(厳密には、SQL Server を使用しているためこうした技術も使用できますが、SharePoint のスキーマ/テーブル構造は公開されていないため、実質、チューニングなどをおこなうのは非常に困難になるでしょう。)
こうした点を無視すると、デフォルトのクォータの制限 (サイトで使用可能な容量の制限) に抵触したり、 パフォーマンスが急激に低下するなど、将来的に多くのトラブルに遭遇してしまうかもしれません。

あなたがサーバー管理者で、利用部門から「こうした目的 (大量データを扱った BI 的な活用) で SharePoint を利用したい」と迫られたなら、Excel Services などを有効化するなどして BI 系の処理に向いた専用のサイトコレクションを立て、データを管理するための専用のデータベース (SQL Server) を準備するなどして、以前のポスト でも説明したように、こうした外部データベースと連携した登録/表示を中心としたダッシュボードの実装などを薦めるべきでしょう。”サイトの管理者” も、部門ごとにサイトの構築をわけたり、年次ごとに分割してリストの構築をおこなって大量データに伴う集計処理は SQL Server 側でおこなうなど、こうした点に配慮して構築をおこなうべきでしょう。(SharePoint 上で RDBMS と同等のぎりぎりの処理を実現しようとしても、破たんする可能性があります。)

またこうした点に配慮すると、データの増加に対しても対策が取りやすくなります。例えば、単一のサイト、単一のリストに大量データが含まれてディスクを圧迫している場合 (しかも、これらのデータは現在も使用されいる) を想像してみてください。もはや API などを使用しなければこうしたデータの効率化は不可能になってしまいます。一方、サイトコレクション単位で調整 (キャパシティプランニング、圧縮の是非の判断、など) が可能な場合には、stsadm.exe コマンドを使ってサイトコレクション単位にコンテンツ DB (SQL Server のデータベース) を分割することが可能であるため、IT Pro / 管理者による制御がしやすくなります。

また、SharePoint のレコードセンター(レコード管理)や、情報管理ポリシーなどの機能を使用して、古いファイルの送信 (収集) や、削除など実施することはできますが、サイトやリストを作成するたびに毎回こうした設定をおこなうのは実際には現実的ではないかもしれません。私の立場で特定企業のソリューション製品をご紹介するのは望ましいことではないかもしれませんが、SharePoint 用のアーカイビングツールなど、SharePoint にはない優れたツールもサードパーティにより提供されていますのでこうしたツールの選択も考慮に入れておくと良いでしょう。

AvePoint DocAve :
http://www.microsoft.com/japan/office/2007/sharepoint/SharePointSolution/AvePoint.mspx#ESJAC

監査、統計情報等の収集 (生涯コストを削減する細めな健診)

監査や統計は、本来、セキュリティや、キャパシティプランニング、実績測定 (KPI) など、さまざまな観点で語る必要があるでしょう。

まず、セキュリティという観点では、ご存じの通り、情報管理ポリシーを使って「監査」の設定をおこなうことができます。監査の結果は Excel のシートなどでダウンロードすることが可能ですが、SPAuditQuery など API を使用することで、独自の視点で監査結果のカスタマイズをおこなうことも可能となります。

http://msdn.microsoft.com/en-us/library/bb466223.aspx

一方、”セキュリティ上の監査” ではなく、記憶領域の “監視” (チェック) などの目的では、SPSite.StorageManagementInformation メソッドを使用することが可能です。(余談ですが、こちらの API は、実は、MVP の溝端さんから教えて頂き、私もその存在をはじめて知りました。)

統計処理には、この他にも、「ユーザの利用状況/アクセス状況」、「人気のあるコンテンツ」、「アクセスされていないリスト」など、”Usage” という観点での統計・集計が必要とされるケースなどもあり、多様のニーズがあります。時には SQL Server のデータベースを直接操作しないと達成できない場面などもあることでしょう。ここではそのすべてを語ることはできませんが、もし皆さんがそうしたニーズに遭遇した場合には、SharePoint Team Blog でも紹介されている以下のドキュメントを見ると、そこに答えやヒントが含まれているかもしれません。

Analyzing Microsoft SharePoint Products and Technologies Usage :
http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm

※1 ただし、このバックアップでは、ワークフロー、フィーチャー、Recycle Bin などについては対象とならないので注意してください。また、SharePoint Designer を使用せず、サーバー側の管理コマンドである stsadm を使用して同じバックアップを取得することも可能です。

※2 ただし、SharePoint はミラー aware ではありませんので、手動での切り替えが必要です。