Sps2013 infrasizing43

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

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は、食べ物と愛猫達の画像がほとんどです。
たまに横浜や旅行先での風景をアップしたりします。
運動が苦手なのですが、水泳とヨガはやっています。
でもヨガだけでは痩せないから、呑み会で摂取したカロリーを
消費するために、まじめに運動しないといけない今日この頃。
(水泳は時間がとれないので休止中。)
ちなみに姉御とか蟒蛇とかよく言われるのですが、そんなことないで
す！
・・・という感じですが、よろしくお願いします。

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

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データベースを保持する

TRADITIONAL TOPOLOGYでの処理の流れ

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

WFE

APP

SQL

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

SQL

BATCH

BATCHはスケジュールで
実行する処理専用
→リソースを集中して使えるから
処理能力がパワーアップ

サービスアプリケーションを実行するサーバーを決めるに
は？
▪ 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

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

TRADITIONAL TOPOLOGYで実行する

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で実行する


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

●


S

User Profile

S

User Profile Synchronization Service

S

BATCH

●

●
●

SEARCH

ENT

STREAMLINED TOPOLOGYで実行する


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

●

●

●

結局、どっちのトポロジがいいの？
▪ ユーザー応答が速くなるならSTREAMLINEDがベスト？
▪ でもSTREAMLINEDだと、FEはWebサーバーの機能に専念できないのです。
▪ FEで実行するサービスアプリケーションを使わない場合やコンテンツの種類によっては、
TRADITIONALにして、Webサーバーの処理に専念にしたほうがページ表示が速くなります。
▪ コンテンツの種類は具体的な例が挙げられないのですが・・・
▪ サービスアプリケーションについては、App Management,Managed Metadata,Secure
Store,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

STREAMLINED

FE

BATCH

DB

STREAMLINEDに検索を追加

FE

BATCH

INDEX

DB

STREAMLINEDに
検索とENTERPRISEを追加

FE

BATCH

INDEX

ENTERPRISE

DB

DB

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

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

検索をパワーアップする！
▪ 下記のマイクロソフト情報を基に新しい検索トポロジについて整理してみましょう。
▪ SharePoint Server 2013 での検索
http://technet.microsoft.com/ja-jp/sharepoint/jj898538
▪ SharePoint Server 2013 での検索の概要
▪ SharePoint Server 2013 の検索アーキテクチャ
oit2013-model-sharepoint-search-architecture.pdf
▪ Enterprise search architectures for SharePoint Server 2013
sp-2013-enterprise-search-model.pdf
▪ パフォーマンスと可用性のために検索を拡張する (SharePoint Server 2013)
▪ 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/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

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

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とします。

INDEX
QUERY
QUERY
INDEX
PARTITION
0
INDEX

APP

APC
CPC
Crawl
Admin

検索コンポーネントの冗長化最小構成
▪ 検索コンポーネントを冗長化する場合は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

検索コンポーネントの冗長構成を拡張する
▪ 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

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

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 2013
sps-2013-enterprise farm-model.pdf
▪ 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

サーバーサイジングの流れ
▪ 総ユーザー数と同時アクセスユーザー数から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)
▪ サポートされている SharePoint データベース用の高可用性と障害復旧のオプション
(SharePoint 2013)

▪ ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2013)
▪ 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

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)

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)

コンテンツデータベース
種類


サイズ傾向

Content database

WSS_Content

200GB-4TB

Content database (個人用サイ
ト)

WSS_Content_Personal

200GB-4TB

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

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)

サービスアプリケーション(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)

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

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

値

ユーザー数

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台



-

-

2台

-

-


10,000

-

-

-

-

2台

り)

500MB

-

-

-

-

Standard機能

使用する

-

-

-

-

1台

Enterprise機能

使用しない

-

-

-

-

-

検索機能

重要

(+1台)

-

-

1台

1台


お試し程度

-

-

-

-

-

冗長構成


＋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

-

-

-

-

-



-

-

-

-

-


10,000

-

-

-

-

-

り)

500MB

-

-

-

-

-

Standard機能

使用する

-

-

-

-

-

Enterprise機能

使用しない

-

-

-

-

-

検索機能

重要

-

-

8Core

8Core

-


お試し程度

-

-

-

-

-

冗長構成


-

-

-

-

-

サイジング例メモリ
項目

値

WFE

APP

IDX

検索
APP

SQL

ユーザー数

10,000

8GB

-

-

-


3,000

8GB
以上

-

-

-


4TB

-

-

-

-

32GB



-

-

-

-

-


10,000

-

-

-

-

32GB

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

500MB

-

-

-

-

Standard機能

使用する

-

-

-

-

32GB

Enterprise機能

使用しない

-

-

-

-

-

検索機能

重要

-

-

24GB

24GB

32GB


お試し程度

-

-

-

-

-

冗長構成


-

-

-

-

-

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

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 のミニブログ機能、フィード、分散キャッシュサービスの概要
▪ SharePoint Server 2013 でフィードおよび分散キャッシュサービスを計画する
▪ 分散キャッシュサービスを管理する (SharePoint Server 2013
http://technet.Microsoft.com/ja-jp/library/jj219613.aspx
▪ SharePoint Server 2013 での分散キャッシュサービスの計画と使用
Plan-and-use-the-Distributed-Cache-service.pdf
▪ 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

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

▪ サーバーに搭載されているメモリサイズの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 からサイジングの表を抜粋
展開の規模

小規模
ファーム

中規模
ファーム

大規模
ファーム

合計ユーザー数

< 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兼用でも動作的な問題はない。

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

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

小規模ファーム

合計ユーザー数

<10,000

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

1GB

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

2GB

推奨されるアーキテクチャ構成

専用またはFEに併置

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

(サーバー)

1台

▪ WFE2台をCache hostとし、1台あたり推奨値1GBを割り当てる。
▪ ファームあたりの合計は2GBになり、推奨値を満たしている。OK!

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 Services
Machine Translation Services
Workflow Services
・Enterprise機能
・Office Web Apps Server ファームなど
• マルチファームの場合もサイジング時に考慮することが多々あります。

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

Sps2013 infrasizing43

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Sps2013 infrasizing43

Similaire à Sps2013 infrasizing43 (20)

Sps2013 infrasizing43