1.
SHAREPOINT2013
INFRA SIZING指南
December 7th 2013
Mayumi Mitaki
Advanced Solution Co,Ltd Manager

2.
SharePoint歴
2007年
以前
某SIerグループ会社に所属。
Windows Server OS,SQL Server の製品評価、
サポート、導入案件を担当。
2007年
SharePoint2007に初めて触る。
2007製品評価、サポートを担当。
Windows Server,MSFC,SQL Serverの導入構築
も継続。
2008年
2009年
2010年
2011年
2012年
2013年
2007製品評価、サポート、構築案件のリーダーを担当
する。
OS,MSFC,SQL,SharePointをまとめて設計、構築す
るチームとして案件を手掛ける。
2007に加えて、2010製品評価、サポート、構築案件
のリーダーを担当。
新規構築、移行案件などで、数千ユーザー～数万
ユーザー規模のファーム構築、コンテンツ移行、バージョン
アップ移行を手掛ける。
某SIerグループ会社から某HW大手ベンダー系列の会
社へ。
SharePoint2010/2013システムの提案を担当。
某HW大手ベンダー系列の会社からアドバンスド・ソリュー
ション株式会社へ電撃移籍(笑)
現在、数社のSharePoint2013インフラ構築の設計と
技術支援を担当。
自己紹介
三瀧 真由美(みたき まゆみ)
アドバンスド・ソリューション株式会社 マネージャー
SharePoint Serverインフラの設計と技術支援を担当しています。
趣味は、着物を着て、落語や狂言を観たり、京都に行ったり、
呑み会に行ったり、美味しいものを作ったり食べたりすることです。
着物を着ていない日も、同じことをします(笑)
facebookは、食べ物と愛猫達の画像がほとんどです。
たまに横浜や旅行先での風景をアップしたりします。
運動が苦手なのですが、水泳とヨガはやっています。
でもヨガだけでは痩せないから、呑み会で摂取したカロリーを
消費するために、まじめに運動しないといけない今日この頃。
(水泳は時間がとれないので休止中。)
ちなみに姉御とか蟒蛇とかよく言われるのですが、そんなことないで
す！
・・・という感じですが、よろしくお願いします。

3.
SHAREPOINT2013 INFRA SIZING 指南とは？
▪ バージョンアップするたびに「違う製品か！」と突っ込みたくなるSharePoint Server・・・
▪ SharePoint Server 2013 も例にもれず。
▪ 以前よりもTechnetに情報がたくさんありますが、膨大な情報量に溺れそう。
▪ そんなSharePoint Server 2013のインフラサイジングを読み解きます。

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

5.
SHAREPOINT2013インフラサイジングで重要な用語
▪ SharePoint は専門用語がたくさんありますが、今回のインフラサイジング指南で重要な用語を挙げます。
用語
概要
トポロジ
構造、構成、形態
ロール
役割
サービスアプリケーション
SharePoint Serverの様々な機能
WFE(Web Front End)
ユーザーに対して最も前面にあり、IIS Webサーバーとしての役割を担うサーバー
FE(Front End)
ユーザーに対して最も前面にあるサーバー
APP(Application)
サービスアプリケーションを実行するサーバー
Batch
ユーザーからのリクエストと直結しないサーバーでの処理を実行するサーバー
INDEX
検索サービスアプリケーションのうち、
インデックスファイルを作成する機能を主として実行するサーバー
検索コンポーネント
検索サービスアプリケーションのもつ様々な機能を担う単位
分散キャッシュ
Windows AppFabric の機能を利用して、複数サーバー
(Cache Cluster) で分散して保持する機能
主にソーシャル機能(ミニブログおよびフィード)のデータを格納する

6.
本日のお題目
▪ 新しいトポロジ
STREAMLINED TOPOLOGY
▪ STREAMLINED TOPOLOGYと
TRADITIONAL TOPOLOGYの違い
▪ 検索をパワーアップする!
▪ 新しい検索トポロジでのサーバー構成
▪ SharePointのサーバーサイジング
▪ 台数、CPU、メモリ、拡張方針の決め方
▪ SQL Serverのサイジング
▪ 台数、CPU、メモリ、拡張方針の決め方
▪ SharePoint2013のデータベース一覧
▪ ファームをサイジングしてみよう！
▪ 分散キャッシュサービス サイジング
▪ まとめ

7.
新しいトポロジ
▪ SharePoint Server 2013 では新しいトポロジの概念が加わりました。
▪ STREAMLINED (合理化された)TOPOLOGY
です。
▪ STREAMLINE TOPOLOGYに対して、2010までのトポロジは
TRADITIONAL (従来の)TOPOLOGY
と呼ばれています。
▪ STREAMLINED TOPOLOGY は、考え方のひとつです。
▪ TRADITIONAL TOPOLOGYはダメ、というわけではありません。

8.
新しいトポロジ
▪ 下記のマイクロソフト情報を基に新しいトポロジについて整理してみましょう。
▪ SharePoint 2013 のアーキテクチャ設計 (IT 担当者向け)
http://technet.microsoft.com/ja-jp/sharepoint/fp123594.aspx
▪ SharePoint 2013 のトポロジ
sps-2013-topology-model.pdf
http://www.microsoft.com/ja-jp/download/details.aspx?id=30377
▪ SharePoint 2013 の合理化されたトポロジ
Streamlined topologies for SharePoint Server 2013
sps-2013-streamlined-topology-model
http://www.microsoft.com/en-us/download/details.aspx?id=37000

9.
2種類のトポロジの違い
▪ 2種類のトポロジ構成の大きな違いは、サービスアプリケーションを実行するロールです。
TRADITIONAL (従来の) TOPOLOGY
WFE
Web Front Endとしてユーザーの最前面に位置し、Webサーバーの役割を実行する
APP/INDEX
サービスアプリケーションを実行する
(インデックス処理が占める割合が大きいためINDEXと呼ぶことが多かった)
DB
SQL Serverを実行し、SharePointデータベースを保持する
STREAMLINED (合理化された) TOPOLGY
FE
Front Endとしてユーザーの最前面に位置し、Webサーバーの役割と、
ユーザーからのリクエストと直結するサービスアプリケーションを実行する
BATCH
ユーザーからのリクエストと直結しない、
バッチ処理的なサービスアプリケーションを実行する
DB
SQL Serverを実行し、SharePointデータベースを保持する

10.
TRADITIONAL TOPOLOGYでの処理の流れ
WFEとAPP間の処理時間が発生する
WFE
APP
SQL

11.
STREAMLINED TOPOLOGYでの処理の流れ
FEはユーザーからのリクエストに専念
→応答処理がスピードアップ
FE
SQL
BATCH
BATCHはスケジュールで
実行する処理専用
→リソースを集中して使えるから
処理能力がパワーアップ

12.
サービスアプリケーションを実行するサーバーを決めるに
は？
▪ STREAMLINED とTRADITIONAL の違いはサービスアプリケーションを実行するサーバーでした。
▪ TRADITIONALでは、サービスアプリケーションをAPPに集約します。
▪ STREAMELINEDでは、FEとBATCHの両方でサービスアプリケーションを実行します。
▪ パワーアップ型では検索とEnterprise機能のサービスアプリケーションをそれぞれ別サーバーで
実行します。
▪ それでは具体的にどのサービスアプリケーションをどのサーバーで実行す
ればよいでしょうか？

13.
サービスアプリケーションを実行するサーバーを決めるに
は？
▪ 下記のマイクロソフト情報を基にサービスアプリケーションについて整理してみましょう。
▪ 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

14.
TRADITIONAL TOPOLOGYで実行する
サービスアプリケーションとサーバー一覧(1)
サービスアプリケーション
WFE
APP
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
●
●
●
INDEX
ENT

15.
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
●
●
●

16.
STREAMLINED TOPOLOGYで実行する
サービスアプリケーションとサーバー一覧(1)
サービスアプリケーション
FE
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
BATCH
●
●
●
SEARCH
ENT

17.
STREAMLINED TOPOLOGYで実行する
サービスアプリケーションとサーバー一覧(2)
サービスアプリケーション
FE
BATCH
SEARCH
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
ENT
●
●
●

18.
結局、どっちのトポロジがいいの？
▪ ユーザー応答が速くなるならSTREAMLINEDがベスト？
▪ でもSTREAMLINEDだと、FEはWebサーバーの機能に専念できないのです。
▪ FEで実行するサービスアプリケーションを使わない場合やコンテンツの種類によっては、
TRADITIONALにして、Webサーバーの処理に専念にしたほうがページ表示が速くなります。
▪ コンテンツの種類は具体的な例が挙げられないのですが・・・
▪ サービスアプリケーションについては、App Management,Managed Metadata,Secure
Store,State,Enterprise機能を使わない、あるいはそれらがメインでない場合は、
TRADITIONALでもよいでしょう。
▪ また、ユーザー数が増加する予定があり、サーバー拡張することが予想される場合も、
TRADITIONAL にして、必要なロールのみ拡張するほうが容易だと考えられます。

19.
結局、どっちのトポロジがいいの？
▪ 実際の案件では、TRADITIONAL TOPOLOGYを選択しました。
▪ 使用するサービスアプリケーションを取捨選択した結果と、Webサーバーをスケールアウトす
る予定があることから、STREAMLINEDにする必要がないと判断しました。
▪ ソーシャル機能やアプリ管理、Managed Metadata を活用する活用するシステムの場合は、
STREAMLINEDを選択してみたいデスネ。
▪ ということで、トポロジを決めるときは、以下の点を検討して考えてみてください。
1.Enterprise機能は使用する？
2.Strandard機能で使用するサービスアプリケーションは？
3.重点的なサービスアプリケーションは？
4.使用しないサービスアプリケーションは？

20.
2種類のトポロジをパワーアップ！
▪ 2種類のトポロジのいずれかに検索機能とEnterprise機能に特化したロールを追加するとパワーアップします。
▪ ただしロール(サーバー)が増えることでサーバーライセンス費用がアップします。ご利用は計画的に。
TRADITIONAL
WFE
APP
DB
TRADITIONALに検索を追加
WFE
APP
INDEX
DB
TRADITIONALに
検索とENTERPRISEを追加
WFE
APP
INDEX
ENTERPRISE
STREAMLINED
FE
BATCH
DB
STREAMLINEDに検索を追加
FE
BATCH
INDEX
DB
STREAMLINEDに
検索とENTERPRISEを追加
FE
BATCH
INDEX
ENTERPRISE
DB
DB

21.
検索をパワーアップする!
▪ TRADITIONALでもSTREAMLINEDでも、検索機能を別サーバーとすることで検索をパワー
アップできます。
▪ ということはINDEXサーバーを追加すればよい？
▪ 半分YES、半分NOです。
▪ SharePoint2013では検索エンジンにFASTが採用され、アーキテクチャーが変更になりました。
▪ アーキテクチャーの変更で、検索トポロジがかなり変わりました。
▪ そのため、検索用のサーバーは以前のように「検索機能を集約したサーバー」にすればいい、
いうわけではないのです。

22.
検索をパワーアップする！
▪ 下記のマイクロソフト情報を基に新しい検索トポロジについて整理してみましょう。
▪ 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.pdf
http://www.microsoft.com/ja-jp/download/details.aspx?id=30374
▪ Enterprise search architectures for SharePoint Server 2013
sp-2013-enterprise-search-model.pdf
http://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

23.
検索をパワーアップする！
▪ 下記はマイクロソフト関連情報ですが、とてもわかりやすいので参考にしましょう。
▪ SharePoint Server 2013 の検索アーキテクチャ
http://blogs.technet.com/b/sharepoint_support/archive/2013/03/01/sharepointserver-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

24.
検索コンポーネントの変更点
2007/2010の検索コンポーネント
2013の検索コンポーネント
Admin
検索管理
Admin
検索管理
CRAWL
クロール処理
CRAWL
クロール処理
INDEX
インデックス処理
CPC New!
コンテンツ処理
QUERY
検索リクエスト応答
APC New!
分析処理
INDEX
インデックス処理
QUERY
検索リクエスト応答

25.
検索トポロジの違い SHAREPOINT2007/2010
インデックス作成の流れ
検索結果レスポンスの流れ
その他

26.
検索トポロジの違い SHAREPOINT2013
インデックス作成の流れ
検索結果レスポンスの流れ
その他

27.
新しい検索トポロジでのサーバー構成
▪ SharePoint2013の検索トポロジではコンポーネントが6種類になっています。
▪ この6種類を集約して実行するサーバーを複数台にすれば、冗長化と可用性はOK？
▪ ということではないのです。メンドクサイネ。
▪ それでは6種類のコンポーネントをどのように配置すればよいでしょうか？

28.
検索コンポーネントモデル
▪ 検索コンポーネントは、INDEX＆QUERYのセットと、それ以外のセットでわけます。
▪ INDEXとQUERYを実行するサーバーをINDEX/QUERYとします。
▪ それ以外(APC,CPC,CRAWL,Admin)を実行するサーバーをAPPとします。
INDEX
QUERY
QUERY
INDEX
PARTITION
0
INDEX
APP
APC
CPC
Crawl
Admin

29.
検索コンポーネントの冗長化 最小構成
▪ 検索コンポーネントを冗長化する場合はINDEX/QUERYとAPPをそれぞれ冗長構成にします。
INDEX1
QUERY1
INDEX2
QUERY2
QUERY
QUERY
REPLICA
REPLICA
▪ この構成で1000万アイテムまで処理できます。
APP2
APC
APC
CPC
CPC
Crawl
Crawl
Admin
INDEX PARTITION 0
APP1
Admin

30.
検索コンポーネントの冗長構成を拡張する
▪ 1000万アイテムを超えたら、INDEX PARTITIONを追加します。
▪ INDEX PARTITIONは1000万アイテム毎に1つ追加します。
▪ INDEX の数は INDEXPARTITIONの倍になります。
INDEX1
INDEX2
QUERY1
INDEX3
INDEX4
QUERY2
INDEX PARTITION 0
REPLICA
REPLICA
QUERY
INDEX PARTITION 1
REPLICA
REPLICA
▪ この構成で2000万アイテムまで処理できます。
APP2
APC
APC
CPC
CPC
Crawl
Crawl
Admin
QUERY
APP1
Admin

31.
検索トポロジモデル (サイジング根拠)
アイテム数
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
クロールされたアイテムの分析 (検索分析) 。
ユーザーが検索結果をどう操作するかの分析 (利用状況分析) 。

32.
検索以外のサーバー台数はどうやって決める？
▪ 検索トポロジモデルを基に検索コンポーネントを実行するサーバーの台数を決めることがわ
かりました。
▪ ところで検索以外のサーバーの台数はどうやって決めたらよいでしょうか？
▪ SharePoint2007/2010ではホワイトペーパーやTechedの資料などがありましたが
▪ SharePoint2013の情報は？

33.
サーバーサイジング
▪ 下記のマイクロソフト情報を基にサーバーサイジングについて整理してみましょう。
▪ 3 層ファームの Web サーバーまたはアプリケーション サーバー
http://technet.microsoft.com/ja-jp/library/cc262485.aspx
▪ Enterprise-scale farms for SharePoint Server 2013
sps-2013-enterprise farm-model.pdf
http://www.microsoft.com/en-us/download/details.aspx?id=35569
▪ Capacity planning for SharePoint Server 2013
http://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

34.
サーバーサイジングの流れ
▪ 総ユーザー数と同時アクセスユーザー数からWFE、APPの台数を決める
▪ WFE、APPのCPUとメモリを決めて、台数を調整する
▪ 総ユーザー数から分散キャッシュサービスのサイズと台数を決める
▪ SQL Serverインスタンス数(＝サーバー台数)を決める
▪ インスタンスのデータベースサイズ合計からSQL ServerサーバーのCPUとメモリを決める
▪ ロールの冗長化が必要な場合は台数を増やす

35.
WFEとAPPのサーバー台数を決める
▪ WFEは1台あたり、一般的に10, 000-20, 000 ユーザーをサポートします。
▪ WFEを冗長構成にする場合は最低2台以上とします。
▪ APPは冗長構成にする場合は最低2台とします。
▪ APPは実行するサービスアプリケーションによってリソースと台数を考慮する必要がありますが
検索トポロジを別にする、Standard機能のみを実行する想定であれば
WFEに準じた台数とします。
▪ なお2台で冗長構成とした場合、単一障害時には縮退運転になります。
▪ 単一障害時の可用性も求められる場合は2台＋1台以上の構成にします。
▪ なお、一部の機能は複数台での冗長化ができないものがあります。

36.
台数が決まったら？
▪ WFEとAPPはユーザー数、冗長構成と可用性の必要性を根拠に台数を決めることがわか
りました。
▪ でもこれは仮決めです。
▪ サーバー1台あたりの処理能力によっては台数を増加する必要があるからです。
▪ 次はサーバーの処理能力にかかせないCPUとメモリをサイジングしましょう。

37.
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ユーザーに対応が
可能になる。

38.
WFEのメモリを決める
▪ WFEのメモリは最小8GB、3 層ファームの Web サーバーまたはアプリケーション サーバー
の場合は最小12 GB。
▪ WFEで分散キャッシュサービスを実行する場合はその分を考慮して追加する。

39.
WFEの拡張方針
▪ WFEを拡張する場合は以下のいずれかで対応する
A) 1台あたりのコア数を8～24に増やし、台数は増やさない (スケールアップ)
B) 1台あたりのコア数は4コアのままは増やさず、台数を増やす (スケールアウト)
※WFEではメモリはあまり重要ではない、かな・・・

40.
APPのCPUとメモリ、拡張方針を決める
▪ APP(アプリケーションサーバー)は最小4コア、4コア以下にはしないことが推奨。
▪ メモリの最小は8GB。
▪ 3 層ファームの Web サーバーまたはアプリケーション サーバーの場合は最小12 GB。
▪ APPを拡張する場合は以下のいずれかで対応する
A) 1台あたりのコア数、メモリを増やし、台数は増やさない (スケールアップ)
B) 1台あたりのコア数、メモリは増やさず、台数を増やす (スケールアウト)

41.
検索トポロジのCPUとメモリを決める
▪ 検索に関するコンポーネントを実行するサーバーのプロセッサは 最小4 コア、推奨8コア。
▪ メモリの推奨値はコンポーネントによって以下のサイズが推奨値となっている。
▪ インデックス コンポーネント 16GB
▪ クエリ処理コンポーネント、クロール コンポーネント、コンテンツ処理コンポーネント(CPC)、
分析処理コンポーネント(APC)、検索管理コンポーネントはそれぞれ8GB。
▪ INDEX/QUERYサーバーはインデックスコンポーネントとクエリ処理コンポーネントが稼働す
るため、16GB+8GB=24GBとする。
▪ 検索トポロジのAPPサーバーはその他4つのコンポーネントが稼働する。
それぞれ8GBだが、8GB×4の合計でなくてもよいため、24GBとする。

42.
検索トポロジの拡張方針を決める
▪ 拡張する場合は以下のいずれかで対応する
A) 1台あたりのコア数、メモリを増やし、台数は増やさない (スケールアップ)
B) 1台あたりのコア数、メモリは増やさず、台数を増やす (スケールアウト)
C) クロールするアイテム数1000万毎にINDEXパーティションを1つ、INDEX2台を1セット
で追加する。
D) クエリコンポーネントはアイテム数8000万で1つ追加する。

43.
SQL SERVERのサイジング
▪ SharePoint Serverのサイジングで終わりではありません。
▪ 実はかなり重要で考えることが多いSQL Serverのサイジング！
▪ 台数はインスタンスの分け方に準じて決めるから後まわしにして、まずはCPUとメモリから。

44.
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.pdf
http://www.microsoft.com/ja-jp/download/details.aspx?id=30363

45.
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とメモリを抑える。

46.
SQL SERVERのインスタンス数と台数を決める
▪ SQL Server 1インスタンスにすべてのデータベースを保持する場合の台数は1台です。
▪ 冗長化はクラスタ構成またはAlwaysOnで実装します。
▪ データベースの役割とサイズによってインスタンスとサーバーをわけることで、SQL Serverの
処理を負荷分散し、SharePointでの処理も向上します。
▪ インスタンスとサーバーをわける場合の冗長化も、クラスタ構成またはAlwaysOnで実装し
ます。
▪ データベースミラーリングはいろいろ条件があるので、あまりオススメではない、かも？
▪ さて、データベースをどのようにわけたらよいでしょうか？

47.
SHAREPOINTデータベースを分類して分散する
▪ SharePoint2013のデータベースは役割から以下の5種類に分類できます。
(1)構成とサービスアプリケーション(Standard機能)
(2)コンテンツデータベース
(3)User Profile サービスアプリケーション
(4)Search サービスアプリケーション
(5)サービスアプリケーション(Enterprise機能)
▪ この5種類を異なるインスタンス＆サーバーにわけることで、SQL Serverの負荷を分散します。

48.
SHAREPOINTデータベースサイズの傾向
▪ SharePoint2013のデータベースのサイズを正確に算出することは難しいです。
▪ 計算式などの情報が公開されていないからです。
▪ そこでtechnetに記載されているサイズの傾向からそれぞれの合計値を予測します。
(1)構成とサービスアプリケーション(Standard機能) 10GB≦1TB
(2)コンテンツデータベース 200GB ≦4TB
(3)User Profile サービスアプリケーション 200GB≦3TB
(4)Search サービスアプリケーション 400GB≦2TB
(5)サービスアプリケーション(Enterprise機能) 100GB ≦1TB

49.
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セットにしたかったデス。

50.
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)

51.
SHAREPOINT2013のデータベース
コンテンツデータベース
種類
データベース名
サイズ傾向
Content database
WSS_Content
200GB-4TB
Content database (個人用サイ
ト)
WSS_Content_Personal
200GB-4TB

52.
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≦)

53.
SHAREPOINT2013のデータベース
SEARCH SERVICE APPLICATION
種類
データベース名
サイズ傾向
Search Administration database
Search_Service_Application_DB_<GUID>
Medium(100GB≦)
Analytics Reporting database
Search_Service_Application_AnalyticsReportingStoreDB_<GUI
D>
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)

54.
SHAREPOINT2013のデータベース
サービスアプリケーション(ENTERPRISE機能)
種類
データベース名
サイズ傾向
Project Server database
ProjectWebApp
Small to Medium
(1GB≦100GB)
Power Pivot database
DefaultPowerPivotServiceApplicationDB_<GUI
D>
Small(≧1GB)
PerformancePoint Services database
PerformancePoint Service _<GUID>
Small(≧1GB)
State Service database
SessionStateService_<GUID>
Medium to large
(100GB≦1TB)

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

56.
ファームサイジング例 前提条件
項目
値
ユーザー数
10,000
同時アクセスユーザー数
3,000
コンテンツデータベースサイズ
4TB
検索アイテム数
1,500万アイテム
個人用サイト利用ユーザー数
10,000
個人用サイトサイズ(1人あた
り)
500MB
Standard機能
使用する
Enterprise機能
使用しない
検索機能
重要
SharePoint2013新機能
お試し程度
冗長構成
最小構成で必須

57.
ファームサイジング例 台数
項目
値
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台
台数合計

58.
サイジング例 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新機能
お試し程度
-
-
-
-
-
冗長構成
最小構成で必須
-
-
-
-
-

59.
サイジング例 メモリ
項目
値
WFE
APP
IDX
検索
APP
SQL
ユーザー数
10,000
8GB
-
-
-
同時アクセスユーザー数
3,000
8GB
以上
-
-
-
コンテンツデータベースサイズ
4TB
-
-
-
-
32GB
検索アイテム数
1,500万アイテム
-
-
-
-
-
個人用サイト利用ユーザー数
10,000
-
-
-
-
32GB
個人用サイトサイズ(1人あたり)
500MB
-
-
-
-
Standard機能
使用する
-
-
-
-
32GB
Enterprise機能
使用しない
-
-
-
-
-
検索機能
重要
-
-
24GB
24GB
32GB
SharePoint2013新機能
お試し程度
-
-
-
-
-
冗長構成
最小構成で必須
-
-
-
-
-

60.
サイジング例 ファームサーバー構成
項目
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以上
※ディスクサイジングの詳細はまたの機会に・・・

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

62.
分散キャッシュサービス サイジング
▪ まだまだ終わりではありません。
▪ SharePoint2013で忘れてはいけない、分散キャッシュサービスのサイジング。
▪ 新しい機能なので？？？状態デスネ。
▪ どんなものかというと、Windows AppFabric の機能を利用して、複数サーバー (Cache
Cluster) でキャッシュを分散して保持する機能です。
▪ ソーシャル機能(ミニブログおよびフィード)のデータを格納します。
▪ さらに以下の機能に必須かつパフォーマンスを向上するそうです。
認証、ニュースフィード、OneNote クライアント アクセス、セキュリティ トリミング、
ページの読み込みパフォーマンス
▪ 分散キャッシュサービスのサイジングは、technetに情報があります。
▪ ※なお、technetの日本語版は情報が少なかったり、間違っていたりするため、英語版も
必ず確認するようにしましょう。

63.
分散キャッシュサービス サイジング
▪ 下記のマイクロソフト情報を基に分散キャッシュサービスのサイジングについて整理してみま
しょう。
▪ 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 2013
http://technet.Microsoft.com/ja-jp/library/jj219613.aspx
▪ SharePoint Server 2013 での分散キャッシュ サービスの計画と使用
Plan-and-use-the-Distributed-Cache-service.pdf
http://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-server2013-preview.aspx
▪ SharePoint 2013 概要および変更点
http://blogs.technet.com/b/sharepoint_support/archive/2013/02/19/sharepoint2013-overview.aspx

64.
分散キャッシュサービスを実行するサーバーの
台数とメモリを決める
▪ 既定では、ファーム構成ウィザード実行時にファーム内のすべてのサーバーで分散キャッシュ
サービスが起動する。
▪ サーバーに搭載されているメモリサイズの10％が分散キャッシュに割り当てられる。
▪ しかし分散キャッシュサービスを実行するサーバー台数は意外と少なく、最低1台あればよい。
▪ なぜなら、キャッシュデータは冗長化ができないし、ファームあたりで必要なサイズも意外と少
ないから。※若干、独断と偏見が入ってます。
▪ 複数台で分散キャッシュサービスを実行すると、それぞれのサーバーが持っているキャッシュ
データは内容が異なっています。
▪ なら複数台の構成は意味ない？
▪ いえいえ、キャッシュデータは冗長化できないのですが、正常なシャットダウン手順を実行す
ると、シャットダウンされるキャッシュ ホストからすべてのキャッシュ データがファーム内の別の
キャッシュ ホストに転送されます。
▪ 1台だけだと専用モード、複数台で実行するのは併用モードと呼びます。
▪ さて、専用モードと併用モードのどちらがよいでしょうか？

65.
分散キャッシュサービスを実行するサーバーの
台数とメモリを決める
▪ キャッシュデータが冗長化できないなら、専用サーバー1台にまとめてしまってもいいのでは？
▪ ただし、分散キャッシュサービス専用サーバーも、SharePoint Server 2013のサーバーライセ
ンスが必要。
▪ ライセンス費用面の問題がなければ、専用サーバー1台にするのもいいかも。
▪ ライセンス費用を抑えたい場合は、FEサーバーで実行して、サーバー台数は増やさない。
▪ 定期メンテナンスなど計画的なサーバー停止を行う運用なら複数台での併用モードで。
▪ FEサーバーで実行する場合は、分散キャッシュサービスに割り当てるメモリ分を追加する。
▪ FEサーバーで実行する場合は、1台に処理が偏らないように、複数台のFEサーバーで
分散キャッシュサービスを実行したほうがよいでしょう。
▪ 分散キャッシュサービスを実行するサーバーをホストと呼び、ホストの集合体をクラスタと呼び
ます。
▪ ファームあたりで必要なサイズはクラスタのサイズです。

66.
分散キャッシュサービスを実行するサーバーの
台数とメモリを決める
▪ SharePoint Server 2013 でフィードおよび分散キャッシュ サービスを計画する
http://technet.microsoft.com/ja-jp/library/jj219572.aspx からサイジングの表を抜粋
展開の規模
小規模
ファーム
中規模
ファーム
大規模
ファーム
合計ユーザー数
< 10,000
< 100,000
< 500,000
分散キャッシュ サービスに推奨される
キャッシュ サイズ
1 GB
2.5 GB
12 GB
分散キャッシュ サービスに対する総メモリ割り当て
(上記の推奨キャッシュ サイズの 2 倍)
2GB
5GB
24GB
推奨されるアーキテクチャ構成
専用または
FEに併置
専用
サーバー
専用
サーバー
ファームあたりの最小キャッシュ ホスト
1
1
1
▪ 1万ユーザーなら専用サーバー1台にするか、FrontEndサーバーで実行してもよい。
▪ 10万ユーザー以上は専用サーバーが推奨だが、FrontEnd兼用でも動作的な問題はない。

67.
分散キャッシュサービスを実行するサーバーの
台数とメモリを決める
▪ 実際の案件ではライセンス費用を抑えるために、FEサーバーで実行して、サーバー台数は
増やさないようにしました。
▪ 実際の案件にならって、さきほどのサイジングしたファームで必要な分散キャッシュをサイジン
グしてみましょう。
展開の規模
小規模ファーム
合計ユーザー数
<10,000
分散キャッシュ サービスに推奨される
キャッシュ サイズ
1GB
分散キャッシュ サービスに対する総メモリ割り当て
(上記の推奨キャッシュ サイズの 2 倍)
2GB
推奨されるアーキテクチャ構成
専用またはFEに併置
ファームあたりの最小キャッシュ ホスト
(サーバー)
1台
▪ WFE2台をCache hostとし、1台あたり推奨値1GBを割り当てる。
▪ ファームあたりの合計は2GBになり、推奨値を満たしている。OK!

68.
まとめ

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

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

71.
SHAREPOINT2013サイジングは
果てしなく続く・・・
• 今日のお題は、新しいトポロジ、検索コンポーネントの理解とサーバーサイジングが中心でした。
• さらに、ディスクサイジング、SQL Server データベース設計、ログ設計とまだまだサイジングは
続きます。
• なお、今日のサイジング指南では、SharePoint2010Standardと同等の機能が使える
ファーム構成をターゲットにしています。
• 以下の機能を使う場合は、別途、サイジングが必要です。
・SharePoint Server 2013 からの新機能
App Management Services
Machine Translation Services
Workflow Services
・Enterprise機能
・Office Web Apps Server ファーム など
• マルチファームの場合もサイジング時に考慮することが多々あります。

72.
最後に
• 今回の指南内容で、実際の案件を設計しています。
• マイクロソフト様のレビューでOKをもらっており、大きな間違いはないハズです。
• お気づきの点などございましたら、本日の休憩時間や懇親会などでお聞かせいただけますと幸
いです。
• 今日は時間がないんだよね、という方は、二言三言、ご相談ください。
• 今回、指南できなかったケースについては、ご要望がありましたらいつの日かまた・・・。
• ご清聴、ありがとうございました。