Sps2013 infrasizing43

SHAREPOINT2013INFRA SIZING指南

December 7th 2013Mayumi Mitaki

Advanced Solution Co,Ltd Manager

自己紹介

SharePoint歴

2007年以前

某SIerグループ会社に所属。Windows Server OS,SQL Server の製品評価、サポート、導入案件を担当。

2007年 SharePoint2007に初めて触る。2007製品評価、サポートを担当。Windows Server,MSFC,SQL Serverの導入構築も継続。

2008年2009年

2007製品評価、サポート、構築案件のリーダーを担当する。OS,MSFC,SQL,SharePointをまとめて設計、構築するチームとして案件を手掛ける。

2010年2011年

2007に加えて、2010製品評価、サポート、構築案件のリーダーを担当。新規構築、移行案件などで、数千ユーザー～数万ユーザー規模のファーム構築、コンテンツ移行、バージョンアップ移行を手掛ける。

2012年 某SIerグループ会社から某HW大手ベンダー系列の会社へ。SharePoint2010/2013システムの提案を担当。

2013年 某HW大手ベンダー系列の会社からアドバンスド・ソリューション株式会社へ電撃移籍(笑)現在、数社のSharePoint2013インフラ構築の設計と技術支援を担当。

三瀧 真由美(みたき まゆみ)

アドバンスド・ソリューション株式会社 マネージャー

SharePoint Serverインフラの設計と技術支援を担当しています。

趣味は、着物を着て、落語や狂言を観たり、京都に行ったり、

呑み会に行ったり、美味しいものを作ったり食べたりすることです。

着物を着ていない日も、同じことをします(笑)

facebookは、食べ物と愛猫達の画像がほとんどです。

たまに横浜や旅行先での風景をアップしたりします。

運動が苦手なのですが、水泳とヨガはやっています。

でもヨガだけでは痩せないから、呑み会で摂取したカロリーを

消費するために、まじめに運動しないといけない今日この頃。

(水泳は時間がとれないので休止中。)

ちなみに姉御とか蟒蛇とかよく言われるのですが、そんなことないです！

・・・という感じですが、よろしくお願いします。

SHAREPOINT2013 INFRA SIZING 指南とは？

▪ バージョンアップするたびに「違う製品か！」と突っ込みたくなるSharePoint Server・・・

▪ SharePoint Server 2013 も例にもれず。

▪ 以前よりもTechnetに情報がたくさんありますが、膨大な情報量に溺れそう。

▪ そんなSharePoint Server 2013のインフラサイジングを読み解きます。

インフラとは？

▪ インフラは infrastructure の略です。

▪ Infrastructureを日本語にすると基盤です。

▪ ITでの基盤は、ハードウェアやネットワーク、それらを配置するデータセンターなどの設備も含まれますが、今回はSharePoint Server ファームを構成するサーバーに限定しています。

SHAREPOINT2013インフラサイジングで重要な用語

▪ SharePoint は専門用語がたくさんありますが、今回のインフラサイジング指南で重要な用語を挙げます。

用語 概要

トポロジ 構造、構成、形態

ロール 役割

サービスアプリケーション SharePoint Serverの様々な機能

WFE(Web Front End) ユーザーに対して最も前面にあり、IIS Webサーバーとしての役割を担うサーバー

FE(Front End) ユーザーに対して最も前面にあるサーバー

APP(Application) サービスアプリケーションを実行するサーバー

Batch ユーザーからのリクエストと直結しないサーバーでの処理を実行するサーバー

INDEX検索サービスアプリケーションのうち、

インデックスファイルを作成する機能を主として実行するサーバー

検索コンポーネント 検索サービスアプリケーションのもつ様々な機能を担う単位

分散キャッシュWindows AppFabric の機能を利用して、複数サーバー

(Cache Cluster) で分散して保持する機能主にソーシャル機能(ミニブログおよびフィード)のデータを格納する

本日のお題目

▪ 新しいトポロジ

STREAMLINED TOPOLOGY

▪ STREAMLINED TOPOLOGYとTRADITIONAL TOPOLOGYの違い

▪ 検索をパワーアップする!

▪ 新しい検索トポロジでのサーバー構成

▪ SharePointのサーバーサイジング

▪ 台数、CPU、メモリ、拡張方針の決め方

▪ SQL Serverのサイジング

▪ 台数、CPU、メモリ、拡張方針の決め方

▪ SharePoint2013のデータベース一覧

▪ ファームをサイジングしてみよう！

▪ 分散キャッシュサービス サイジング

▪ まとめ

新しいトポロジ

▪ SharePoint Server 2013 では新しいトポロジの概念が加わりました。

▪ STREAMLINED (合理化された)TOPOLOGY です。

▪ STREAMLINE TOPOLOGYに対して、2010までのトポロジは

TRADITIONAL (従来の)TOPOLOGY と呼ばれています。

▪ STREAMLINED TOPOLOGYは、考え方のひとつです。

▪ TRADITIONAL TOPOLOGYはダメ、というわけではありません。

新しいトポロジ

▪ 下記のマイクロソフト情報を基に新しいトポロジについて整理してみましょう。

▪ SharePoint 2013 のアーキテクチャ設計 (IT 担当者向け) http://technet.microsoft.com/ja-jp/sharepoint/fp123594.aspx

▪ SharePoint 2013 のトポロジsps-2013-topology-model.pdfhttp://www.microsoft.com/ja-jp/download/details.aspx?id=30377

▪ SharePoint 2013 の合理化されたトポロジStreamlined topologies for SharePoint Server 2013 sps-2013-streamlined-topology-modelhttp://www.microsoft.com/en-us/download/details.aspx?id=37000

2種類のトポロジの違い

▪ 2種類のトポロジ構成の大きな違いは、サービスアプリケーションを実行するロールです。

TRADITIONAL (従来の) TOPOLOGY

WFE Web Front Endとしてユーザーの最前面に位置し、Webサーバーの役割を実行する

APP/INDEXサービスアプリケーションを実行する

(インデックス処理が占める割合が大きいためINDEXと呼ぶことが多かった)

DB SQL Serverを実行し、SharePointデータベースを保持する

STREAMLINED (合理化された) TOPOLGY

FEFront Endとしてユーザーの最前面に位置し、Webサーバーの役割と、ユーザーからのリクエストと直結するサービスアプリケーションを実行する

BATCHユーザーからのリクエストと直結しない、

バッチ処理的なサービスアプリケーションを実行する

DB SQL Serverを実行し、SharePointデータベースを保持する

TRADITIONAL TOPOLOGYでの処理の流れ

WFEとAPP間の処理時間が発生する

WFE APP SQL

STREAMLINED TOPOLOGYでの処理の流れ

FEはユーザーからのリクエストに専念→応答処理がスピードアップ

BATCHはスケジュールで実行する処理専用

→リソースを集中して使えるから処理能力がパワーアップ

FE

BATCH

SQL

サービスアプリケーションを実行するサーバーを決めるには？

▪ STREAMLINED とTRADITIONAL の違いはサービスアプリケーションを実行するサーバーでした。

▪ TRADITIONALでは、サービスアプリケーションをAPPに集約します。

▪ STREAMELINEDでは、FEとBATCHの両方でサービスアプリケーションを実行します。

▪ パワーアップ型では検索とEnterprise機能のサービスアプリケーションをそれぞれ別サーバーで実行します。

▪ それでは具体的にどのサービスアプリケーションをどのサーバーで実行すればよいでしょうか？

サービスアプリケーションを実行するサーバーを決めるには？

▪ 下記のマイクロソフト情報を基にサービスアプリケーションについて整理してみましょう。

▪ SharePoint 2013 でサービス展開を計画するhttp://technet.microsoft.com/ja-jp/library/jj219591.aspx

▪ 簡略化されたトポロジのサーバーのサービスhttp://technet.microsoft.com/ja-jp/library/jj219591.aspx#Section1

※簡略化されたとなっていますがSTREAMLINEDのことです。

▪ 従来のトポロジの [サーバーのサービスhttp://technet.microsoft.com/ja-jp/library/jj219591.aspx#Section2

TRADITIONAL TOPOLOGYで実行するサービスアプリケーションとサーバー一覧(1)

サービスアプリケーション WFE APP INDEX ENT

App Management Service S ●

Business Data Connectivity S ●

Machine Translation Service S ●

Managed Metadata Service S ●

Microsoft SharePoint Foundation Subscription Settings Service

S ● ●

Secure Store Service S ●

State Service S ●

Usage and Health Data Collection S ●

User Profile S ●

User Profile Synchronization Service S ●

TRADITIONAL TOPOLOGYで実行するサービスアプリケーションとサーバー一覧(2)

サービスアプリケーション WFE APP INDEX ENT

Work Management S ●

Word Automation Service S ●

Search S ● ●

Access Services 2010 E ● ●

Access Services E ● ●

Excel Services E ● ●

PerformancePoint E ● ●

PowerPoint Conversion E ● ●

Visio Graphics Service E ● ●

STREAMLINED TOPOLOGYで実行するサービスアプリケーションとサーバー一覧(1)

サービスアプリケーション FE BATCH SEARCH ENT

App Management Service S ●

Business Data Connectivity S ●

Machine Translation Service S ●

Managed Metadata Service S ●

Microsoft SharePoint Foundation Subscription Settings Service

S ●

Secure Store Service S ●

State Service S ●

Usage and Health Data Collection S

User Profile S ●

User Profile Synchronization Service S ●

STREAMLINED TOPOLOGYで実行するサービスアプリケーションとサーバー一覧(2)

サービスアプリケーション FE BATCH SEARCH ENT

Work Management S ●

Word Automation Service S ● ●

Search S ● ●

Access Services 2010 E ●

Access Services E ●

Excel Services E ● ●

PerformancePoint E ● ●

PowerPoint Conversion E ●

Visio Graphics Service E ●

結局、どっちのトポロジがいいの？

▪ ユーザー応答が速くなるならSTREAMLINEDがベスト？

▪ でもSTREAMLINEDだと、FEはWebサーバーの機能に専念できないのです。

▪ FEで実行するサービスアプリケーションを使わない場合やコンテンツの種類によっては、TRADITIONALにして、Webサーバーの処理に専念にしたほうがページ表示が速くなります。

▪ コンテンツの種類は具体的な例が挙げられないのですが・・・

▪ サービスアプリケーションについては、App Management,Managed Metadata,SecureStore,State,Enterprise機能を使わない、あるいはそれらがメインでない場合は、TRADITIONALでもよいでしょう。

▪ また、ユーザー数が増加する予定があり、サーバー拡張することが予想される場合も、TRADITIONALにして、必要なロールのみ拡張するほうが容易だと考えられます。

結局、どっちのトポロジがいいの？

▪ 実際の案件では、TRADITIONAL TOPOLOGYを選択しました。

▪ 使用するサービスアプリケーションを取捨選択した結果と、Webサーバーをスケールアウトする予定があることから、STREAMLINEDにする必要がないと判断しました。

▪ ソーシャル機能やアプリ管理、Managed Metadata を活用する活用するシステムの場合は、STREAMLINEDを選択してみたいデスネ。

▪ ということで、トポロジを決めるときは、以下の点を検討して考えてみてください。

1.Enterprise機能は使用する？

2.Strandard機能で使用するサービスアプリケーションは？

3.重点的なサービスアプリケーションは？

4.使用しないサービスアプリケーションは？

2種類のトポロジをパワーアップ！

▪ 2種類のトポロジのいずれかに検索機能とEnterprise機能に特化したロールを追加するとパワーアップします。

▪ ただしロール(サーバー)が増えることでサーバーライセンス費用がアップします。ご利用は計画的に。

TRADITIONAL WFE APP DB

TRADITIONALに検索を追加 WFE APP INDEX DB

TRADITIONALに検索とENTERPRISEを追加

WFE APP INDEX ENTERPRISE DB

STREAMLINED FE BATCH DB

STREAMLINEDに検索を追加 FE BATCH INDEX DB

STREAMLINEDに検索とENTERPRISEを追加

FE BATCH INDEX ENTERPRISE DB

検索をパワーアップする!

▪ TRADITIONALでもSTREAMLINEDでも、検索機能を別サーバーとすることで検索をパワーアップできます。

▪ ということはINDEXサーバーを追加すればよい？

▪ 半分YES、半分NOです。

▪ SharePoint2013では検索エンジンにFASTが採用され、アーキテクチャーが変更になりました。

▪ アーキテクチャーの変更で、検索トポロジがかなり変わりました。

▪ そのため、検索用のサーバーは以前のように「検索機能を集約したサーバー」にすればいい、いうわけではないのです。

検索をパワーアップする！

▪ 下記のマイクロソフト情報を基に新しい検索トポロジについて整理してみましょう。

▪ SharePoint Server 2013 での検索http://technet.microsoft.com/ja-jp/sharepoint/jj898538

▪ SharePoint Server 2013 での検索の概要http://technet.microsoft.com/ja-jp/library/jj219738.aspx

▪ SharePoint Server 2013 の検索アーキテクチャoit2013-model-sharepoint-search-architecture.pdfhttp://www.microsoft.com/ja-jp/download/details.aspx?id=30374

▪ Enterprise search architectures for SharePoint Server 2013 sp-2013-enterprise-search-model.pdfhttp://www.microsoft.com/en-us/download/details.aspx?id=30383

▪ パフォーマンスと可用性のために検索を拡張する (SharePoint Server 2013)http://technet.microsoft.com/ja-jp/library/jj219628.aspx

▪ Performance and capacity test results and recommendations (SharePoint Server 2013)http://technet.microsoft.com/en-us/library/ff608068.aspx

検索をパワーアップする！

▪ 下記はマイクロソフト関連情報ですが、とてもわかりやすいので参考にしましょう。

▪ SharePoint Server 2013 の検索アーキテクチャhttp://blogs.technet.com/b/sharepoint_support/archive/2013/03/01/sharepoint-server-2013.aspx

▪ SharePoint 2013 検索機能のすゝめ (1) http://sharepointsearch.org/2012/11/21/sharepoint-2013-%e6%a4%9c%e7%b4%a2%e6%a9%9f%e8%83%bd%e3%81%ae%e3%81%99%e3%82%9d%e3%82%81-1/

▪ SharePoint 2013 検索機能のすゝめ (5) http://sharepointsearch.org/2013/04/17/sharepoint-2013-%e6%a4%9c%e7%b4%a2%e6%a9%9f%e8%83%bd%e3%81%ae%e3%81%99%e3%82%9d%e3%82%81-5/?relatedposts_exclude=678

検索コンポーネントの変更点

2007/2010の検索コンポーネント 2013の検索コンポーネント

Admin 検索管理 Admin 検索管理

CRAWL クロール処理 CRAWL クロール処理

INDEX インデックス処理 CPC New! コンテンツ処理

QUERY 検索リクエスト応答 APC New! 分析処理

INDEX インデックス処理

QUERY 検索リクエスト応答

検索トポロジの違い SHAREPOINT2007/2010

インデックス作成の流れ

検索結果レスポンスの流れ

その他

検索トポロジの違い SHAREPOINT2013

インデックス作成の流れ

検索結果レスポンスの流れ

その他

新しい検索トポロジでのサーバー構成

▪ SharePoint2013の検索トポロジではコンポーネントが6種類になっています。

▪ この6種類を集約して実行するサーバーを複数台にすれば、冗長化と可用性はOK？

▪ ということではないのです。メンドクサイネ。

▪ それでは6種類のコンポーネントをどのように配置すればよいでしょうか？

検索コンポーネントモデル

▪ 検索コンポーネントは、INDEX＆QUERYのセットと、それ以外のセットでわけます。

▪ INDEXとQUERYを実行するサーバーをINDEX/QUERYとします。

▪ それ以外(APC,CPC,CRAWL,Admin)を実行するサーバーをAPPとします。

INDEXQUERY

INDEX PARTITION

0

INDEX

QUERY

APP

APC

CPC

Crawl

Admin

検索コンポーネントの冗長化 最小構成

▪ 検索コンポーネントを冗長化する場合はINDEX/QUERYとAPPをそれぞれ冗長構成にします。

▪ この構成で1000万アイテムまで処理できます。

INDEX2QUERY2

INDEX1QUERY1

INDEX PARTITION 0

REPLICA REPLICA

QUERY

APP1

APC

CPC

Crawl

Admin

APP2

APC

CPC

Crawl

Admin

QUERY

検索コンポーネントの冗長構成を拡張する

▪ 1000万アイテムを超えたら、INDEX PARTITIONを追加します。

▪ INDEX PARTITIONは1000万アイテム毎に1つ追加します。

▪ INDEXの数は INDEXPARTITIONの倍になります。

▪ この構成で2000万アイテムまで処理できます。

INDEX2QUERY1

INDEX1

INDEX PARTITION 0

REPLICA REPLICA

QUERY

APP1

APC

CPC

Crawl

Admin

APP2

APC

CPC

Crawl

Admin

INDEX4QUERY2

INDEX3

INDEX PARTITION 1

REPLICA REPLICA

QUERY

検索トポロジモデル (サイジング根拠)

アイテム数 1千万 4千万 1億 説明

インデックスサイズ(TB) 0.5 2.0 5.0 1000万アイテム毎に500GB。またはコンテンツソースサイズの10～15%。

コンテンツサイズ(TB) 3 13 33

INDEX 2 8 20 CPCから処理されたアイテムを受取り、インデックス ファイルに書き込む。冗長構成にする場合は、インデックスパーティション数の倍数になる。

INDEX PARTITION 1 4 10 1000万アイテム毎に 1個のインデックス パーティションを追加(推奨)。冗長化する場合は1台つき1個のREPLICAをもつ。

Query (クエリ処理) 2 2 2 検索クエリおよび結果を分析して処理する。8000万アイテム毎に1コンポーネントを追加(推奨)。

Admin (検索管理) 2 2 2 検索で重要なさまざまなシステム プロセスを実行。

Crawl (クロール) 2 2 2 コンテンツ ソースのクロールを実行。

CPC (コンテンツ処理) 2 4 6 クロールされたアイテムを処理し、インデックス コンポーネントに渡す。

APC (分析処理) 2 2 6 クロールされたアイテムの分析 (検索分析) 。ユーザーが検索結果をどう操作するかの分析 (利用状況分析) 。

検索以外のサーバー台数はどうやって決める？

▪ 検索トポロジモデルを基に検索コンポーネントを実行するサーバーの台数を決めることがわかりました。

▪ ところで検索以外のサーバーの台数はどうやって決めたらよいでしょうか？

▪ SharePoint2007/2010ではホワイトペーパーやTechedの資料などがありましたが

▪ SharePoint2013の情報は？

サーバーサイジング

▪ 下記のマイクロソフト情報を基にサーバーサイジングについて整理してみましょう。

▪ 3 層ファームの Web サーバーまたはアプリケーション サーバーhttp://technet.microsoft.com/ja-jp/library/cc262485.aspx

▪ Enterprise-scale farms for SharePoint Server 2013sps-2013-enterprise farm-model.pdfhttp://www.microsoft.com/en-us/download/details.aspx?id=35569

▪ Capacity planning for SharePoint Server 2013http://technet.microsoft.com/en-us/library/ff758645.aspx

▪ ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)http://technet.microsoft.com/ja-jp/library/cc298801(office.14).aspx

▪ 仮想 SharePoint 2013 ファームの詳細な設計とシステム仕様の処理

アーキテクチャ モデルおよびシステム仕様を更新するhttp://technet.microsoft.com/JA-JP/library/ff607864.aspx#Virtual2

サーバーサイジングの流れ

▪ 総ユーザー数と同時アクセスユーザー数からWFE、APPの台数を決める

▪ WFE、APPのCPUとメモリを決めて、台数を調整する

▪ 総ユーザー数から分散キャッシュサービスのサイズと台数を決める

▪ SQL Serverインスタンス数(＝サーバー台数)を決める

▪ インスタンスのデータベースサイズ合計からSQL ServerサーバーのCPUとメモリを決める

▪ ロールの冗長化が必要な場合は台数を増やす

WFEとAPPのサーバー台数を決める

▪ WFEは1台あたり、一般的に10, 000-20, 000 ユーザーをサポートします。

▪ WFEを冗長構成にする場合は最低2台以上とします。

▪ APPは冗長構成にする場合は最低2台とします。

▪ APPは実行するサービスアプリケーションによってリソースと台数を考慮する必要がありますが

検索トポロジを別にする、Standard機能のみを実行する想定であれば

WFEに準じた台数とします。

▪ なお2台で冗長構成とした場合、単一障害時には縮退運転になります。

▪ 単一障害時の可用性も求められる場合は2台＋1台以上の構成にします。

▪ なお、一部の機能は複数台での冗長化ができないものがあります。

台数が決まったら？

▪ WFEとAPPはユーザー数、冗長構成と可用性の必要性を根拠に台数を決めることがわかりました。

▪ でもこれは仮決めです。

▪ サーバー1台あたりの処理能力によっては台数を増加する必要があるからです。

▪ 次はサーバーの処理能力にかかせないCPUとメモリをサイジングしましょう。

WFEのCPUを決める

▪ WFEは最小4コア、推奨8コア、最大24コア。

▪ 4コア以下にはしないことが推奨。

▪ WFEは一般的に10, 000-20, 000 ユーザーをサポートする。

▪ WFEの処理速度はCPU数に依存する。

▪ 4コアで同時アクセス 2,000-2,500ユーザーに対応する。

▪ 8コアとすることで 同時アクセス 4,000-5,000ユーザーに対応する。

▪ 1台あたり最小4コアとする場合は、2台で同時アクセス 4,000-5,000ユーザーに対応が可能になる。

WFEのメモリを決める

▪ WFEのメモリは最小8GB、3 層ファームの Web サーバーまたはアプリケーション サーバーの場合は最小12 GB。

▪ WFEで分散キャッシュサービスを実行する場合はその分を考慮して追加する。

WFEの拡張方針

▪ WFEを拡張する場合は以下のいずれかで対応する

A) 1台あたりのコア数を8～24に増やし、台数は増やさない (スケールアップ)

B) 1台あたりのコア数は4コアのままは増やさず、台数を増やす (スケールアウト)

※WFEではメモリはあまり重要ではない、かな・・・

APPのCPUとメモリ、拡張方針を決める

▪ APP(アプリケーションサーバー)は最小4コア、4コア以下にはしないことが推奨。

▪ メモリの最小は8GB。

▪ 3 層ファームの Web サーバーまたはアプリケーション サーバーの場合は最小12 GB。

▪ APPを拡張する場合は以下のいずれかで対応する

A) 1台あたりのコア数、メモリを増やし、台数は増やさない (スケールアップ)

B) 1台あたりのコア数、メモリは増やさず、台数を増やす (スケールアウト)

検索トポロジのCPUとメモリを決める

▪ 検索に関するコンポーネントを実行するサーバーのプロセッサは 最小4 コア、推奨8コア。

▪ メモリの推奨値はコンポーネントによって以下のサイズが推奨値となっている。

▪ インデックス コンポーネント 16GB

▪ クエリ処理コンポーネント、クロール コンポーネント、コンテンツ処理コンポーネント(CPC)、

分析処理コンポーネント(APC)、検索管理コンポーネントはそれぞれ8GB。

▪ INDEX/QUERYサーバーはインデックスコンポーネントとクエリ処理コンポーネントが稼働するため、16GB+8GB=24GBとする。

▪ 検索トポロジのAPPサーバーはその他4つのコンポーネントが稼働する。

それぞれ8GBだが、8GB×4の合計でなくてもよいため、24GBとする。

検索トポロジの拡張方針を決める

▪ 拡張する場合は以下のいずれかで対応する

A) 1台あたりのコア数、メモリを増やし、台数は増やさない (スケールアップ)

B) 1台あたりのコア数、メモリは増やさず、台数を増やす (スケールアウト)

C) クロールするアイテム数1000万毎にINDEXパーティションを1つ、INDEX2台を1セットで追加する。

D) クエリコンポーネントはアイテム数8000万で1つ追加する。

SQL SERVERのサイジング

▪ SharePoint Serverのサイジングで終わりではありません。

▪ 実はかなり重要で考えることが多いSQL Serverのサイジング！

▪ 台数はインスタンスの分け方に準じて決めるから後まわしにして、まずはCPUとメモリから。

SQL SERER サーバーサイジング

▪ 下記のマイクロソフト情報を基にSQL Serverのサーバーサイジングについて整理してみましょう。

▪ データベースの種類と説明 (SharePoint 2013) http://technet.microsoft.com/ja-jp/library/cc678868.aspx

▪ サポートされている SharePoint データベース用の高可用性と障害復旧のオプション(SharePoint 2013) http://technet.microsoft.com/ja-jp/library/jj841106.aspx

▪ ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2013) http://technet.microsoft.com/ja-jp/library/cc298801.aspx

▪ SharePoint 環境内の SQL Server の概要 (SharePoint 2013) http://technet.microsoft.com/ja-jp/library/ff945791.aspx

▪ SharePoint Server ファーム内の SQL Server のベストプラクティスhttp://technet.microsoft.com/ja-jp/library/hh292622.aspx

▪ SharePoint 2013 をサポートしているデータベースitpro-2013-db-poster.pdfhttp://www.microsoft.com/ja-jp/download/details.aspx?id=30363

SQL SERVERのCPUとメモリを決める

▪ 中規模展開(1,000 ～ 10,000 ユーザー)の場合、8コア が最小値

▪ 中規模展開(1,000 ～ 10,000 ユーザー)の場合、メモリは16GBが最小値

▪ データベースサイズが最大2TBの場合、メモリは32GBが推奨値

▪ データベースサイズが最大4TBの場合、メモリは64GBが推奨値

コア数、メモリを減らす場合の条件

▪ 最小値の8コアより減らした場合、SQL Serverの処理能力が低下し、SharePointの処理も低下する可能性がある。

▪ データベースの役割とサイズによってSQL Server のインスタンスとサーバーをわけることで、1台あたりのCPUとメモリを抑える。

SQL SERVERのインスタンス数と台数を決める

▪ SQL Server 1インスタンスにすべてのデータベースを保持する場合の台数は1台です。

▪ 冗長化はクラスタ構成またはAlwaysOnで実装します。

▪ データベースの役割とサイズによってインスタンスとサーバーをわけることで、SQL Serverの

処理を負荷分散し、SharePointでの処理も向上します。

▪ インスタンスとサーバーをわける場合の冗長化も、クラスタ構成またはAlwaysOnで実装します。

▪ データベースミラーリングはいろいろ条件があるので、あまりオススメではない、かも？

▪ さて、データベースをどのようにわけたらよいでしょうか？

SHAREPOINTデータベースを分類して分散する

▪ SharePoint2013のデータベースは役割から以下の5種類に分類できます。

(1)構成とサービスアプリケーション(Standard機能)

(2)コンテンツデータベース

(3)User Profileサービスアプリケーション

(4)Searchサービスアプリケーション

(5)サービスアプリケーション(Enterprise機能)

▪ この5種類を異なるインスタンス＆サーバーにわけることで、SQL Serverの負荷を分散します。

SHAREPOINTデータベースサイズの傾向

▪ SharePoint2013のデータベースのサイズを正確に算出することは難しいです。

▪ 計算式などの情報が公開されていないからです。

▪ そこでtechnetに記載されているサイズの傾向からそれぞれの合計値を予測します。

(1)構成とサービスアプリケーション(Standard機能) 10GB≦1TB

(2)コンテンツデータベース 200GB ≦4TB

(3)User Profileサービスアプリケーション 200GB≦3TB

(4)Searchサービスアプリケーション 400GB≦2TB

(5)サービスアプリケーション(Enterprise機能) 100GB ≦1TB

SHAREPOINTデータベースサイズの傾向

▪ 1インスタンスあたりのデータベース最大サイズが4TB以内になりました。メモリ64GBでOK！

▪ メモリ32GBの上限値である2TB以内にするためには、(2)(3)のデータベースをさらに分散させましょう。

▪ 冗長構成はクラスタまたはAlwaysOnで実装します。

▪ クラスタの場合、5台×2node=10台！？ にしなくても大丈夫です。

▪ たとえば、2nodeのActive/Activeを2セット、2nodeのActive/Passiveを1セットで計6台です。

▪ 5nodeのActive/Activeを1セットにして計5台も可能です。

※ただし国内事例はないらしいです。

▪ 実際の案件では、Enterprise機能用インスタンスなしで、2nodeのActive/Activeを2セットにしました。

▪ お金があれば、3nodeで2Active/1Passiveを2セットにしたかったデス。

SHAREPOINT2013のデータベース構成とサービスアプリケーション(STANDARD機能)

種類 データベース名 サイズ傾向

Configuration database SharePoint_Config Small(≧1GB)

Central Administration content database SharePoint_AdminContent_<GUID> Small(≧1GB)

App Management database AppManagement Small(≧1GB)

Business Data Connectivity database Bdc_Service_DB_<GUID> Small(≧1GB)

Secure Store database Secure_Store_Service_DB_<GUID> Small(≧1GB)

Usage and Health Data Collection database

SharePoint_Logging Extra large(1TB≦)

Subscription Settings database SettingsServiceDB Small(≧1GB)

Word Automation Services database WordAutomationServices_<GUID> Small(≧1GB)

Managed Metadata database Managed Metadata Service Application_Metadata_<GUID> Medium(100GB≦)

Machine Translation Services database SharePoint Translation Services_<GUID> Small(≧1GB)

SHAREPOINT2013のデータベースコンテンツデータベース

種類 データベース名 サイズ傾向

Content database WSS_Content 200GB-4TB

Content database (個人用サイト)

WSS_Content_Personal 200GB-4TB

SHAREPOINT2013のデータベースUSER PROFILE APPLICATION

種類 データベース名 サイズ傾向

Profile database User Profile Service Application_ProfileDB_<GUID>

Medium to large(100GB≦1TB)

Synchronization database

User Profile Service Application_SyncDB_<GUID> Medium to large(100GB≦1TB)

Social Tagging database User Profile Service Application_SocialDB_<GUID>

Small to extra-large(1GB≦1TB≦)

SHAREPOINT2013のデータベースSEARCH SERVICE APPLICATION

種類 データベース名 サイズ傾向

Search Administration database Search_Service_Application_DB_<GUID> Medium(100GB≦)

Analytics Reporting database Search_Service_Application_AnalyticsReportingStoreDB_<GUID>

Medium to large(100GB≦1TB)

Crawl database Search_Service_Application_CrawlStoreDB_<GUID> Medium(100GB≦)

Link database Search_Service_Application_LinkStoreDB_<GUID> Medium to large(100GB≦1TB)

SHAREPOINT2013のデータベースサービスアプリケーション(ENTERPRISE機能)

種類 データベース名 サイズ傾向

Project Server database ProjectWebApp Small to Medium(1GB≦100GB)

Power Pivot database DefaultPowerPivotServiceApplicationDB_<GUID>

Small(≧1GB)

PerformancePoint Services database PerformancePoint Service _<GUID> Small(≧1GB)

State Service database SessionStateService_<GUID> Medium to large(100GB≦1TB)

ファームをサイジングしてみよう！

ファームサイジング例 前提条件

項目 値

ユーザー数 10,000

同時アクセスユーザー数 3,000

コンテンツデータベースサイズ 4TB

検索アイテム数 1,500万アイテム

個人用サイト利用ユーザー数 10,000

個人用サイトサイズ(1人あたり)

500MB

Standard機能 使用する

Enterprise機能 使用しない

検索機能 重要

SharePoint2013新機能 お試し程度

冗長構成 最小構成で必須

ファームサイジング例 台数

項目 値 WFE APP IDX 検索APP

SQL

ユーザー数 10,000 1台 1台 - - -

同時アクセスユーザー数 3,000 - - -

コンテンツデータベースサイズ 4TB - - - - 2台

検索アイテム数 1,500万アイテム - - 2台 - -

個人用サイト利用ユーザー数 10,000 - - - - 2台

個人用サイトサイズ(1人あたり)

500MB - - - -

Standard機能 使用する - - - - 1台

Enterprise機能 使用しない - - - - -

検索機能 重要 (+1台) - - 1台 1台

SharePoint2013新機能 お試し程度 - - - - -

冗長構成 最小構成で必須 ＋1台 +1台

+2台 +1台

クラスタActive/Active

台数合計 2台 2台 4台 2台 6台

サイジング例 CPU

項目 値 WFE APP IDX 検索APP

SQL

ユーザー数 10,000 4Core 4Core - - 8core

同時アクセスユーザー数 3,000 - - -

コンテンツデータベースサイズ 4TB - - - - -

検索アイテム数 1,500万アイテム - - - - -

個人用サイト利用ユーザー数 10,000 - - - - -

個人用サイトサイズ(1人あたり)

500MB - - - - -

Standard機能 使用する - - - - -

Enterprise機能 使用しない - - - - -

検索機能 重要 - - 8Core 8Core -

SharePoint2013新機能 お試し程度 - - - - -

冗長構成 最小構成で必須 - - - - -

サイジング例 メモリ

項目 値 WFE APP IDX 検索APP

SQL

ユーザー数 10,000 8GB 8GB以上

- - -

同時アクセスユーザー数 3,000 - - -

コンテンツデータベースサイズ 4TB - - - - 32GB

検索アイテム数 1,500万アイテム - - - - -

個人用サイト利用ユーザー数 10,000 - - - - 32GB

個人用サイトサイズ(1人あたり) 500MB - - - -

Standard機能 使用する - - - - 32GB

Enterprise機能 使用しない - - - - -

検索機能 重要 - - 24GB 24GB 32GB

SharePoint2013新機能 お試し程度 - - - - -

冗長構成 最小構成で必須 - - - - -

サイジング例 ファームサーバー構成

項目 WFE APP IDX 検索APP SQL

台数 2台 2台 4台 2台 4台

CPU 4Core 4Core 8Core 8Core 8Core

メモリ 8GB 8GB 24GB 24GB 32GB

Disk(Cドライブ) 120GB 120GB 160GB 160GB 200GB

Disk(Dドライブ) 300GB 300GB 700GB 400GB 3TB以上

※ディスクサイジングの詳細はまたの機会に・・・

サイジング例でのファーム構成

分散キャッシュサービス サイジング

▪ まだまだ終わりではありません。

▪ SharePoint2013で忘れてはいけない、分散キャッシュサービスのサイジング。

▪ 新しい機能なので？？？状態デスネ。

▪ どんなものかというと、Windows AppFabric の機能を利用して、複数サーバー (Cache Cluster) でキャッシュを分散して保持する機能です。

▪ ソーシャル機能(ミニブログおよびフィード)のデータを格納します。

▪ さらに以下の機能に必須かつパフォーマンスを向上するそうです。

認証、ニュースフィード、OneNote クライアント アクセス、セキュリティ トリミング、

ページの読み込みパフォーマンス

▪ 分散キャッシュサービスのサイジングは、technetに情報があります。

▪ ※なお、technetの日本語版は情報が少なかったり、間違っていたりするため、英語版も必ず確認するようにしましょう。

分散キャッシュサービス サイジング

▪ 下記のマイクロソフト情報を基に分散キャッシュサービスのサイジングについて整理してみましょう。

▪ SharePoint Server 2013 のミニブログ機能、フィード、分散キャッシュ サービスの概要http://technet.microsoft.com/ja-jp/library/jj219700.aspx

▪ SharePoint Server 2013 でフィードおよび分散キャッシュ サービスを計画するhttp://technet.microsoft.com/ja-jp/library/jj219572.aspx

▪ 分散キャッシュサービスを管理する (SharePoint Server 2013http://technet.Microsoft.com/ja-jp/library/jj219613.aspx

▪ SharePoint Server 2013 での分散キャッシュサービスの計画と使用Plan-and-use-the-Distributed-Cache-service.pdfhttp://www.microsoft.com/ja-jp/download/details.aspx?id=35557

▪ SharePoint Server 2013 Preview の分散キャッシュサービスの紹介http://blogs.msdn.com/b/sharepoint_jp/archive/2012/09/20/sharepoint-server-2013-preview.aspx

▪ SharePoint 2013 概要および変更点http://blogs.technet.com/b/sharepoint_support/archive/2013/02/19/sharepoint-2013-overview.aspx

分散キャッシュサービスを実行するサーバーの台数とメモリを決める

▪ 既定では、ファーム構成ウィザード実行時にファーム内のすべてのサーバーで分散キャッシュサービスが起動する。

▪ サーバーに搭載されているメモリサイズの10％が分散キャッシュに割り当てられる。

▪ しかし分散キャッシュサービスを実行するサーバー台数は意外と少なく、最低1台あればよい。

▪ なぜなら、キャッシュデータは冗長化ができないし、ファームあたりで必要なサイズも意外と少ないから。※若干、独断と偏見が入ってます。

▪ 複数台で分散キャッシュサービスを実行すると、それぞれのサーバーが持っているキャッシュデータは内容が異なっています。

▪ なら複数台の構成は意味ない？

▪ いえいえ、キャッシュデータは冗長化できないのですが、正常なシャットダウン手順を実行すると、シャットダウンされるキャッシュホストからすべてのキャッシュ データがファーム内の別のキャッシュホストに転送されます。

▪ 1台だけだと専用モード、複数台で実行するのは併用モードと呼びます。

▪ さて、専用モードと併用モードのどちらがよいでしょうか？

分散キャッシュサービスを実行するサーバーの台数とメモリを決める

▪ キャッシュデータが冗長化できないなら、専用サーバー1台にまとめてしまってもいいのでは？

▪ ただし、分散キャッシュサービス専用サーバーも、SharePoint Server 2013のサーバーライセンスが必要。

▪ ライセンス費用面の問題がなければ、専用サーバー1台にするのもいいかも。

▪ ライセンス費用を抑えたい場合は、FEサーバーで実行して、サーバー台数は増やさない。

▪ 定期メンテナンスなど計画的なサーバー停止を行う運用なら複数台での併用モードで。

▪ FEサーバーで実行する場合は、分散キャッシュサービスに割り当てるメモリ分を追加する。

▪ FEサーバーで実行する場合は、1台に処理が偏らないように、複数台のFEサーバーで

分散キャッシュサービスを実行したほうがよいでしょう。

▪ 分散キャッシュサービスを実行するサーバーをホストと呼び、ホストの集合体をクラスタと呼びます。

▪ ファームあたりで必要なサイズはクラスタのサイズです。

分散キャッシュサービスを実行するサーバーの台数とメモリを決める

▪ SharePoint Server 2013 でフィードおよび分散キャッシュサービスを計画するhttp://technet.microsoft.com/ja-jp/library/jj219572.aspx からサイジングの表を抜粋

▪ 1万ユーザーなら専用サーバー1台にするか、FrontEndサーバーで実行してもよい。

▪ 10万ユーザー以上は専用サーバーが推奨だが、FrontEnd兼用でも動作的な問題はない。

展開の規模 小規模ファーム

中規模ファーム

大規模ファーム

合計ユーザー数 < 10,000 < 100,000 < 500,000

分散キャッシュ サービスに推奨されるキャッシュ サイズ

1 GB 2.5 GB 12 GB

分散キャッシュ サービスに対する総メモリ割り当て(上記の推奨キャッシュ サイズの 2 倍)

2GB 5GB 24GB

推奨されるアーキテクチャ構成 専用またはFEに併置

専用サーバー

専用サーバー

ファームあたりの最小キャッシュ ホスト 1 1 1

分散キャッシュサービスを実行するサーバーの台数とメモリを決める

▪ 実際の案件ではライセンス費用を抑えるために、FEサーバーで実行して、サーバー台数は増やさないようにしました。

▪ 実際の案件にならって、さきほどのサイジングしたファームで必要な分散キャッシュをサイジングしてみましょう。

▪ WFE2台をCache hostとし、1台あたり推奨値1GBを割り当てる。

▪ ファームあたりの合計は2GBになり、推奨値を満たしている。OK!

展開の規模 小規模ファーム

合計ユーザー数 <10,000

分散キャッシュ サービスに推奨されるキャッシュ サイズ

1GB

分散キャッシュ サービスに対する総メモリ割り当て(上記の推奨キャッシュ サイズの 2 倍)

2GB

推奨されるアーキテクチャ構成 専用またはFEに併置

ファームあたりの最小キャッシュ ホスト (サーバー) 1台

まとめ

SHAREPOINT2013のサイジング・トポロジを決めるために、どの機能を使うかを決める・トポロジを決める・ロールと、ロールで実行するサービスアプリケーションを決める・検索機能の強化が必要かを決める・検索アイテム数から検索コンポーネントの台数を決める・コンテンツデータベースのサイズを予測する・個人用サイトを使用するユーザー数と1人あたりのサイズ上限を決める・総ユーザー数と同時アクセスユーザー数からWFE、APPの台数を決める・WFE、APPのCPUとメモリと台数を調整する・総ユーザー数から分散キャッシュサービスのサイズと台数を決める・SQL Serverインスタンス数(＝サーバー台数)を決める・インスタンスのデータベースサイズ合計からSQL ServerサーバーのCPUとメモリを決める・ロールの冗長化が必要な場合は台数を増やす

SHAREPOINT2013のサイジングに最低限必要な情報・ユーザー数・同時アクセスユーザー数・コンテンツデータベースサイズ・検索アイテム数・個人用サイト利用ユーザー数・個人用サイトサイズ(1人あたり)・Standard機能・Enterprise機能・検索機能・SharePoint2013新機能・冗長構成

SHAREPOINT2013サイジングは果てしなく続く・・・• 今日のお題は、新しいトポロジ、検索コンポーネントの理解とサーバーサイジングが中心でした。• さらに、ディスクサイジング、SQL Server データベース設計、ログ設計とまだまだサイジングは続きます。

• なお、今日のサイジング指南では、SharePoint2010Standardと同等の機能が使えるファーム構成をターゲットにしています。

• 以下の機能を使う場合は、別途、サイジングが必要です。・SharePoint Server 2013 からの新機能App Management ServicesMachine Translation ServicesWorkflow Services・Enterprise機能・Office Web Apps Server ファーム など

• マルチファームの場合もサイジング時に考慮することが多々あります。

最後に• 今回の指南内容で、実際の案件を設計しています。

• マイクロソフト様のレビューでOKをもらっており、大きな間違いはないハズです。

• お気づきの点などございましたら、本日の休憩時間や懇親会などでお聞かせいただけますと幸いです。

• 今日は時間がないんだよね、という方は、二言三言、ご相談ください。

• 今回、指南できなかったケースについては、ご要望がありましたらいつの日かまた・・・。

• ご清聴、ありがとうございました。