Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sps2013 infrasizing43

4,453 views

Published on

SharePoint Server 2013 Infra Sizing

  • Be the first to comment

Sps2013 infrasizing43

  1. 1. SHAREPOINT2013 INFRA SIZING指南 December 7th 2013 Mayumi Mitaki Advanced Solution Co,Ltd Manager
  2. 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. 3. SHAREPOINT2013 INFRA SIZING 指南とは? ▪ バージョンアップするたびに「違う製品か!」と突っ込みたくなるSharePoint Server・・・ ▪ SharePoint Server 2013 も例にもれず。 ▪ 以前よりもTechnetに情報がたくさんありますが、膨大な情報量に溺れそう。 ▪ そんなSharePoint Server 2013のインフラサイジングを読み解きます。
  4. 4. インフラとは? ▪ インフラは infrastructure の略です。 ▪ Infrastructureを日本語にすると基盤です。 ▪ ITでの基盤は、ハードウェアやネットワーク、それらを配置するデータセンターなどの設備も含 まれますが、今回はSharePoint Server ファームを構成するサーバーに限定しています。
  5. 5. SHAREPOINT2013インフラサイジングで重要な用語 ▪ SharePoint は専門用語がたくさんありますが、今回のインフラサイジング指南で重要な用語を挙げます。 用語 概要 トポロジ 構造、構成、形態 ロール 役割 サービスアプリケーション SharePoint Serverの様々な機能 WFE(Web Front End) ユーザーに対して最も前面にあり、IIS Webサーバーとしての役割を担うサーバー FE(Front End) ユーザーに対して最も前面にあるサーバー APP(Application) サービスアプリケーションを実行するサーバー Batch ユーザーからのリクエストと直結しないサーバーでの処理を実行するサーバー INDEX 検索サービスアプリケーションのうち、 インデックスファイルを作成する機能を主として実行するサーバー 検索コンポーネント 検索サービスアプリケーションのもつ様々な機能を担う単位 分散キャッシュ Windows AppFabric の機能を利用して、複数サーバー (Cache Cluster) で分散して保持する機能 主にソーシャル機能(ミニブログおよびフィード)のデータを格納する
  6. 6. 本日のお題目 ▪ 新しいトポロジ STREAMLINED TOPOLOGY ▪ STREAMLINED TOPOLOGYと TRADITIONAL TOPOLOGYの違い ▪ 検索をパワーアップする! ▪ 新しい検索トポロジでのサーバー構成 ▪ SharePointのサーバーサイジング ▪ 台数、CPU、メモリ、拡張方針の決め方 ▪ SQL Serverのサイジング ▪ 台数、CPU、メモリ、拡張方針の決め方 ▪ SharePoint2013のデータベース一覧 ▪ ファームをサイジングしてみよう! ▪ 分散キャッシュサービス サイジング ▪ まとめ
  7. 7. 新しいトポロジ ▪ SharePoint Server 2013 では新しいトポロジの概念が加わりました。 ▪ STREAMLINED (合理化された)TOPOLOGY です。 ▪ STREAMLINE TOPOLOGYに対して、2010までのトポロジは TRADITIONAL (従来の)TOPOLOGY と呼ばれています。 ▪ STREAMLINED TOPOLOGY は、考え方のひとつです。 ▪ TRADITIONAL TOPOLOGYはダメ、というわけではありません。
  8. 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. 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. 10. TRADITIONAL TOPOLOGYでの処理の流れ WFEとAPP間の処理時間が発生する WFE APP SQL
  11. 11. STREAMLINED TOPOLOGYでの処理の流れ FEはユーザーからのリクエストに専念 →応答処理がスピードアップ FE SQL BATCH BATCHはスケジュールで 実行する処理専用 →リソースを集中して使えるから 処理能力がパワーアップ
  12. 12. サービスアプリケーションを実行するサーバーを決めるに は? ▪ STREAMLINED とTRADITIONAL の違いはサービスアプリケーションを実行するサーバーでした。 ▪ TRADITIONALでは、サービスアプリケーションをAPPに集約します。 ▪ STREAMELINEDでは、FEとBATCHの両方でサービスアプリケーションを実行します。 ▪ パワーアップ型では検索とEnterprise機能のサービスアプリケーションをそれぞれ別サーバーで 実行します。 ▪ それでは具体的にどのサービスアプリケーションをどのサーバーで実行す ればよいでしょうか?
  13. 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. 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. 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. 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. 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. 18. 結局、どっちのトポロジがいいの? ▪ ユーザー応答が速くなるならSTREAMLINEDがベスト? ▪ でもSTREAMLINEDだと、FEはWebサーバーの機能に専念できないのです。 ▪ FEで実行するサービスアプリケーションを使わない場合やコンテンツの種類によっては、 TRADITIONALにして、Webサーバーの処理に専念にしたほうがページ表示が速くなります。 ▪ コンテンツの種類は具体的な例が挙げられないのですが・・・ ▪ サービスアプリケーションについては、App Management,Managed Metadata,Secure Store,State,Enterprise機能を使わない、あるいはそれらがメインでない場合は、 TRADITIONALでもよいでしょう。 ▪ また、ユーザー数が増加する予定があり、サーバー拡張することが予想される場合も、 TRADITIONAL にして、必要なロールのみ拡張するほうが容易だと考えられます。
  19. 19. 結局、どっちのトポロジがいいの? ▪ 実際の案件では、TRADITIONAL TOPOLOGYを選択しました。 ▪ 使用するサービスアプリケーションを取捨選択した結果と、Webサーバーをスケールアウトす る予定があることから、STREAMLINEDにする必要がないと判断しました。 ▪ ソーシャル機能やアプリ管理、Managed Metadata を活用する活用するシステムの場合は、 STREAMLINEDを選択してみたいデスネ。 ▪ ということで、トポロジを決めるときは、以下の点を検討して考えてみてください。 1.Enterprise機能は使用する? 2.Strandard機能で使用するサービスアプリケーションは? 3.重点的なサービスアプリケーションは? 4.使用しないサービスアプリケーションは?
  20. 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. 21. 検索をパワーアップする! ▪ TRADITIONALでもSTREAMLINEDでも、検索機能を別サーバーとすることで検索をパワー アップできます。 ▪ ということはINDEXサーバーを追加すればよい? ▪ 半分YES、半分NOです。 ▪ SharePoint2013では検索エンジンにFASTが採用され、アーキテクチャーが変更になりました。 ▪ アーキテクチャーの変更で、検索トポロジがかなり変わりました。 ▪ そのため、検索用のサーバーは以前のように「検索機能を集約したサーバー」にすればいい、 いうわけではないのです。
  22. 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. 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. 24. 検索コンポーネントの変更点 2007/2010の検索コンポーネント 2013の検索コンポーネント Admin 検索管理 Admin 検索管理 CRAWL クロール処理 CRAWL クロール処理 INDEX インデックス処理 CPC New! コンテンツ処理 QUERY 検索リクエスト応答 APC New! 分析処理 INDEX インデックス処理 QUERY 検索リクエスト応答
  25. 25. 検索トポロジの違い SHAREPOINT2007/2010 インデックス作成の流れ 検索結果レスポンスの流れ その他
  26. 26. 検索トポロジの違い SHAREPOINT2013 インデックス作成の流れ 検索結果レスポンスの流れ その他
  27. 27. 新しい検索トポロジでのサーバー構成 ▪ SharePoint2013の検索トポロジではコンポーネントが6種類になっています。 ▪ この6種類を集約して実行するサーバーを複数台にすれば、冗長化と可用性はOK? ▪ ということではないのです。メンドクサイネ。 ▪ それでは6種類のコンポーネントをどのように配置すればよいでしょうか?
  28. 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. 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. 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. 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. 32. 検索以外のサーバー台数はどうやって決める? ▪ 検索トポロジモデルを基に検索コンポーネントを実行するサーバーの台数を決めることがわ かりました。 ▪ ところで検索以外のサーバーの台数はどうやって決めたらよいでしょうか? ▪ SharePoint2007/2010ではホワイトペーパーやTechedの資料などがありましたが ▪ SharePoint2013の情報は?
  33. 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. 34. サーバーサイジングの流れ ▪ 総ユーザー数と同時アクセスユーザー数からWFE、APPの台数を決める ▪ WFE、APPのCPUとメモリを決めて、台数を調整する ▪ 総ユーザー数から分散キャッシュサービスのサイズと台数を決める ▪ SQL Serverインスタンス数(=サーバー台数)を決める ▪ インスタンスのデータベースサイズ合計からSQL ServerサーバーのCPUとメモリを決める ▪ ロールの冗長化が必要な場合は台数を増やす
  35. 35. WFEとAPPのサーバー台数を決める ▪ WFEは1台あたり、一般的に10, 000-20, 000 ユーザーをサポートします。 ▪ WFEを冗長構成にする場合は最低2台以上とします。 ▪ APPは冗長構成にする場合は最低2台とします。 ▪ APPは実行するサービスアプリケーションによってリソースと台数を考慮する必要がありますが 検索トポロジを別にする、Standard機能のみを実行する想定であれば WFEに準じた台数とします。 ▪ なお2台で冗長構成とした場合、単一障害時には縮退運転になります。 ▪ 単一障害時の可用性も求められる場合は2台+1台以上の構成にします。 ▪ なお、一部の機能は複数台での冗長化ができないものがあります。
  36. 36. 台数が決まったら? ▪ WFEとAPPはユーザー数、冗長構成と可用性の必要性を根拠に台数を決めることがわか りました。 ▪ でもこれは仮決めです。 ▪ サーバー1台あたりの処理能力によっては台数を増加する必要があるからです。 ▪ 次はサーバーの処理能力にかかせないCPUとメモリをサイジングしましょう。
  37. 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. 38. WFEのメモリを決める ▪ WFEのメモリは最小8GB、3 層ファームの Web サーバーまたはアプリケーション サーバー の場合は最小12 GB。 ▪ WFEで分散キャッシュサービスを実行する場合はその分を考慮して追加する。
  39. 39. WFEの拡張方針 ▪ WFEを拡張する場合は以下のいずれかで対応する A) 1台あたりのコア数を8~24に増やし、台数は増やさない (スケールアップ) B) 1台あたりのコア数は4コアのままは増やさず、台数を増やす (スケールアウト) ※WFEではメモリはあまり重要ではない、かな・・・
  40. 40. APPのCPUとメモリ、拡張方針を決める ▪ APP(アプリケーションサーバー)は最小4コア、4コア以下にはしないことが推奨。 ▪ メモリの最小は8GB。 ▪ 3 層ファームの Web サーバーまたはアプリケーション サーバーの場合は最小12 GB。 ▪ APPを拡張する場合は以下のいずれかで対応する A) 1台あたりのコア数、メモリを増やし、台数は増やさない (スケールアップ) B) 1台あたりのコア数、メモリは増やさず、台数を増やす (スケールアウト)
  41. 41. 検索トポロジのCPUとメモリを決める ▪ 検索に関するコンポーネントを実行するサーバーのプロセッサは 最小4 コア、推奨8コア。 ▪ メモリの推奨値はコンポーネントによって以下のサイズが推奨値となっている。 ▪ インデックス コンポーネント 16GB ▪ クエリ処理コンポーネント、クロール コンポーネント、コンテンツ処理コンポーネント(CPC)、 分析処理コンポーネント(APC)、検索管理コンポーネントはそれぞれ8GB。 ▪ INDEX/QUERYサーバーはインデックスコンポーネントとクエリ処理コンポーネントが稼働す るため、16GB+8GB=24GBとする。 ▪ 検索トポロジのAPPサーバーはその他4つのコンポーネントが稼働する。 それぞれ8GBだが、8GB×4の合計でなくてもよいため、24GBとする。
  42. 42. 検索トポロジの拡張方針を決める ▪ 拡張する場合は以下のいずれかで対応する A) 1台あたりのコア数、メモリを増やし、台数は増やさない (スケールアップ) B) 1台あたりのコア数、メモリは増やさず、台数を増やす (スケールアウト) C) クロールするアイテム数1000万毎にINDEXパーティションを1つ、INDEX2台を1セット で追加する。 D) クエリコンポーネントはアイテム数8000万で1つ追加する。
  43. 43. SQL SERVERのサイジング ▪ SharePoint Serverのサイジングで終わりではありません。 ▪ 実はかなり重要で考えることが多いSQL Serverのサイジング! ▪ 台数はインスタンスの分け方に準じて決めるから後まわしにして、まずはCPUとメモリから。
  44. 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. 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. 46. SQL SERVERのインスタンス数と台数を決める ▪ SQL Server 1インスタンスにすべてのデータベースを保持する場合の台数は1台です。 ▪ 冗長化はクラスタ構成またはAlwaysOnで実装します。 ▪ データベースの役割とサイズによってインスタンスとサーバーをわけることで、SQL Serverの 処理を負荷分散し、SharePointでの処理も向上します。 ▪ インスタンスとサーバーをわける場合の冗長化も、クラスタ構成またはAlwaysOnで実装し ます。 ▪ データベースミラーリングはいろいろ条件があるので、あまりオススメではない、かも? ▪ さて、データベースをどのようにわけたらよいでしょうか?
  47. 47. SHAREPOINTデータベースを分類して分散する ▪ SharePoint2013のデータベースは役割から以下の5種類に分類できます。 (1)構成とサービスアプリケーション(Standard機能) (2)コンテンツデータベース (3)User Profile サービスアプリケーション (4)Search サービスアプリケーション (5)サービスアプリケーション(Enterprise機能) ▪ この5種類を異なるインスタンス&サーバーにわけることで、SQL Serverの負荷を分散します。
  48. 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. 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. 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. 51. SHAREPOINT2013のデータベース コンテンツデータベース 種類 データベース名 サイズ傾向 Content database WSS_Content 200GB-4TB Content database (個人用サイ ト) WSS_Content_Personal 200GB-4TB
  52. 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. 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. 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. 55. ファームをサイジングしてみよう!
  56. 56. ファームサイジング例 前提条件 項目 値 ユーザー数 10,000 同時アクセスユーザー数 3,000 コンテンツデータベースサイズ 4TB 検索アイテム数 1,500万アイテム 個人用サイト利用ユーザー数 10,000 個人用サイトサイズ(1人あた り) 500MB Standard機能 使用する Enterprise機能 使用しない 検索機能 重要 SharePoint2013新機能 お試し程度 冗長構成 最小構成で必須
  57. 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. 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. 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. 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. 61. サイジング例でのファーム構成
  62. 62. 分散キャッシュサービス サイジング ▪ まだまだ終わりではありません。 ▪ SharePoint2013で忘れてはいけない、分散キャッシュサービスのサイジング。 ▪ 新しい機能なので???状態デスネ。 ▪ どんなものかというと、Windows AppFabric の機能を利用して、複数サーバー (Cache Cluster) でキャッシュを分散して保持する機能です。 ▪ ソーシャル機能(ミニブログおよびフィード)のデータを格納します。 ▪ さらに以下の機能に必須かつパフォーマンスを向上するそうです。 認証、ニュースフィード、OneNote クライアント アクセス、セキュリティ トリミング、 ページの読み込みパフォーマンス ▪ 分散キャッシュサービスのサイジングは、technetに情報があります。 ▪ ※なお、technetの日本語版は情報が少なかったり、間違っていたりするため、英語版も 必ず確認するようにしましょう。
  63. 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. 64. 分散キャッシュサービスを実行するサーバーの 台数とメモリを決める ▪ 既定では、ファーム構成ウィザード実行時にファーム内のすべてのサーバーで分散キャッシュ サービスが起動する。 ▪ サーバーに搭載されているメモリサイズの10%が分散キャッシュに割り当てられる。 ▪ しかし分散キャッシュサービスを実行するサーバー台数は意外と少なく、最低1台あればよい。 ▪ なぜなら、キャッシュデータは冗長化ができないし、ファームあたりで必要なサイズも意外と少 ないから。※若干、独断と偏見が入ってます。 ▪ 複数台で分散キャッシュサービスを実行すると、それぞれのサーバーが持っているキャッシュ データは内容が異なっています。 ▪ なら複数台の構成は意味ない? ▪ いえいえ、キャッシュデータは冗長化できないのですが、正常なシャットダウン手順を実行す ると、シャットダウンされるキャッシュ ホストからすべてのキャッシュ データがファーム内の別の キャッシュ ホストに転送されます。 ▪ 1台だけだと専用モード、複数台で実行するのは併用モードと呼びます。 ▪ さて、専用モードと併用モードのどちらがよいでしょうか?
  65. 65. 分散キャッシュサービスを実行するサーバーの 台数とメモリを決める ▪ キャッシュデータが冗長化できないなら、専用サーバー1台にまとめてしまってもいいのでは? ▪ ただし、分散キャッシュサービス専用サーバーも、SharePoint Server 2013のサーバーライセ ンスが必要。 ▪ ライセンス費用面の問題がなければ、専用サーバー1台にするのもいいかも。 ▪ ライセンス費用を抑えたい場合は、FEサーバーで実行して、サーバー台数は増やさない。 ▪ 定期メンテナンスなど計画的なサーバー停止を行う運用なら複数台での併用モードで。 ▪ FEサーバーで実行する場合は、分散キャッシュサービスに割り当てるメモリ分を追加する。 ▪ FEサーバーで実行する場合は、1台に処理が偏らないように、複数台のFEサーバーで 分散キャッシュサービスを実行したほうがよいでしょう。 ▪ 分散キャッシュサービスを実行するサーバーをホストと呼び、ホストの集合体をクラスタと呼び ます。 ▪ ファームあたりで必要なサイズはクラスタのサイズです。
  66. 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. 67. 分散キャッシュサービスを実行するサーバーの 台数とメモリを決める ▪ 実際の案件ではライセンス費用を抑えるために、FEサーバーで実行して、サーバー台数は 増やさないようにしました。 ▪ 実際の案件にならって、さきほどのサイジングしたファームで必要な分散キャッシュをサイジン グしてみましょう。 展開の規模 小規模ファーム 合計ユーザー数 <10,000 分散キャッシュ サービスに推奨される キャッシュ サイズ 1GB 分散キャッシュ サービスに対する総メモリ割り当て (上記の推奨キャッシュ サイズの 2 倍) 2GB 推奨されるアーキテクチャ構成 専用またはFEに併置 ファームあたりの最小キャッシュ ホスト (サーバー) 1台 ▪ WFE2台をCache hostとし、1台あたり推奨値1GBを割り当てる。 ▪ ファームあたりの合計は2GBになり、推奨値を満たしている。OK!
  68. 68. まとめ
  69. 69. SHAREPOINT2013のサイジング ・トポロジを決めるために、どの機能を使うかを決める ・トポロジを決める ・ロールと、ロールで実行するサービスアプリケーションを決める ・検索機能の強化が必要かを決める ・検索アイテム数から検索コンポーネントの台数を決める ・コンテンツデータベースのサイズを予測する ・個人用サイトを使用するユーザー数と1人あたりのサイズ上限を決める ・総ユーザー数と同時アクセスユーザー数からWFE、APPの台数を決める ・WFE、APPのCPUとメモリと台数を調整する ・総ユーザー数から分散キャッシュサービスのサイズと台数を決める ・SQL Serverインスタンス数(=サーバー台数)を決める ・インスタンスのデータベースサイズ合計からSQL ServerサーバーのCPUとメモリを決める ・ロールの冗長化が必要な場合は台数を増やす
  70. 70. SHAREPOINT2013のサイジングに 最低限必要な情報 ・ユーザー数 ・同時アクセスユーザー数 ・コンテンツデータベースサイズ ・検索アイテム数 ・個人用サイト利用ユーザー数 ・個人用サイトサイズ(1人あたり) ・Standard機能 ・Enterprise機能 ・検索機能 ・SharePoint2013新機能 ・冗長構成
  71. 71. SHAREPOINT2013サイジングは 果てしなく続く・・・ • 今日のお題は、新しいトポロジ、検索コンポーネントの理解とサーバーサイジングが中心でした。 • さらに、ディスクサイジング、SQL Server データベース設計、ログ設計とまだまだサイジングは 続きます。 • なお、今日のサイジング指南では、SharePoint2010Standardと同等の機能が使える ファーム構成をターゲットにしています。 • 以下の機能を使う場合は、別途、サイジングが必要です。 ・SharePoint Server 2013 からの新機能 App Management Services Machine Translation Services Workflow Services ・Enterprise機能 ・Office Web Apps Server ファーム など • マルチファームの場合もサイジング時に考慮することが多々あります。
  72. 72. 最後に • 今回の指南内容で、実際の案件を設計しています。 • マイクロソフト様のレビューでOKをもらっており、大きな間違いはないハズです。 • お気づきの点などございましたら、本日の休憩時間や懇親会などでお聞かせいただけますと幸 いです。 • 今日は時間がないんだよね、という方は、二言三言、ご相談ください。 • 今回、指南できなかったケースについては、ご要望がありましたらいつの日かまた・・・。 • ご清聴、ありがとうございました。

×