*Microsoft Feed

2018/06/14

Office365 と Trend Micro Cloud App Security でより安全なクラウドへ(後編)

前回はTrend Micro Cloud App Security(以下、TMCAS) の評価導入の

ステップをお伝えしました。



前回記事はこちら↓
Office365 と Trend Micro Cloud App Security でより安全なクラウドへ
(前編)

 

後編となる今回は、TMCASの管理機能の解説と、実際にウィルス検知時に

どのような動作となるか、ご紹介したいと思います。

TMCASの検索方法としては、システムが自動で検索処理を行う「リアル

タイム検索」と管理者が都度実行する「手動検索」方法があります。
 
※無料評価版の制限として「リアルタイム検索」が利用不可となっています。

そのため検知時の処理に関しては「手動検索」による結果を記載しています。

TMCASの基本的な管理はWebコンソールを利用します。

ログインすると最初に以下のようなダッシュボードが表示されます。

ダッシュボードでは、全体の利用状況のグラフ表示などで確認できます。

検知数などのリンクをクリックすると検知ログの一覧などに遷移します。

Dashboard_4

ダッシュボードをはじめ管理コンソールは以下のパーツで構成されています。

・高度な脅威対策

Image7
・情報漏えい対策

Image24
・ログ

Image36
・隔離

Image37

・運用管理

Image38

上記パーツのうち、セキュリティ運用のルール(ポリシー)を設定する箇所が

「高度な脅威対策」と「情報漏洩対策」です。

TMCASではOffice 365 のサービス毎(Exchange、SharePoint、OneDrive

上記2つのポリシーを定義して利用する事になります。


TMCASのテナントを開設した時点でそれぞれ既定のポリシーが構成されて

います。


「高度な脅威対策」は、ウィルス対策、Web および ファイルレピュテー

ションに関するポリシーを定義します。



「情報漏洩対策」は、データ損失保護(DLP)に関わる部分で、マイナンバー

などの個人情報や機密情報の流出保護に関するポリシーを定義します。


1つのサービスにつき複数のポリシーを作成する事が出来ますのでユーザー

グループ単位で異なるポリシーを割り当てることが可能です。


今回は一例として、Exchange Online に対して「高度な脅威対策ポリシー」

紹介したいと思います。

「一般」ではリアルタイム検索の有効/無効、ポリシーの優先度および、

対象のユーザー/グループを指定します。

Image9

「高度なスパムメール対策」では、スパムメール対策の有効/無効を設定し、

検索範囲および検知レベルのルール設定と、検知後の処理、通知の有無を

指定します。   

Image10

Image12

Image13

「不正プログラム検索」では、不正プログラムの検索範囲や機械学習を

用いた検索の有効/無効のルール設定と、検知後の処理、通知を指定します。

Image15

 

「ファイルブロック」では、特定の拡張子をもつファイルをブロックする

ルール設定を指定します。

Image17

「Webレピュテーション」では、不審URLに対する検索範囲や検知レベルを

指定します。

Image19

「仮想アナライザ」では、TMCASのサンドボックス処理による振る舞い

検知に関するルールを指定します。


Image21

上記は例として Exchange Online の「高度な脅威対策」ポリシーを見て

きましたが、TMCASによって実際に検知/処理がどのような挙動となるか

試したいと思います。


検知に利用するのはテスト用ウィルスとしてお馴染みの「eicar」を使用

して、、と言いたいところですが、今回は趣向を変えて Office 365の

機能を利用して不審URLを含んだメールによる挙動を試してみたいと

思います。

今回利用するOffice 365の機能は「Office 365 攻撃シミュレーター

(Attack Simulator)」を利用します



ご存知の方もいらっしゃると思いますが、Office 365 攻撃シミュ

レーターは、Office 365 E5プランで提供されており、管理者は

以下に挙げる3つの攻撃シミュレーションを試す事が出来るように

なっています。

・スピアフィッシング攻撃
・ブルートフォース辞書攻撃
・パスワードスプレー攻撃

Attack
ちなみにこの 攻撃シミュレーター ですが、実行可能なユーザーの前提条件

としてOffice 365の多要素認証(MFA)を有効化する必要があります。

ですので、TMCASから少し脱線しますが Office 365 のMFAおよび攻撃

シミュレーターの手順についても簡単に触れたいと思います。

※既にMFAを利用されている方は、この説明はスキップして下さい。



まず、Office 365管理者ポータルに管理者アカウントでアクセスします。

ユーザー>アクティブなユーザー画面に移動し、ユーザーを選択し

「Azure Mult Fac..」をクリックします。

Image2

多要素認証を有効化するユーザーを選択し、画面右側の「有効」をクリック

します。

Image4

続いて、「multi facter authを有効にする」をクリックします。

Image5
処理が正常終了した旨のメッセージを確認し、「閉じる」をクリックします。

Image6

その後、別のブラウザを立ち上げ、有効化したユーザーでOffice 365ポータル

にアクセスし、いつものようにID、PWを入力します。

Image8

すると追加の認証を求める画面が表示されますので、「今すぐセットアップ

する」をクリックします。

Image11

追加のセキュリティ画面で連絡方法を選択します。

Image12

MFAのパターンとしては、電話への認証コードの送信あるいは通話に応答

するパターンと、「Microsoft Authenticator(以下、Authenticator)

いう専用のモバイルアプリを利用するパターンがあります。


今回はAuthenticator を利用したいので「モバイルアプリ」を選択して

進めます。

Image13

続いてどのような方法で多要素認証を行うかを問われますので、今回は

「確認コードを使用する」を選択し「セットアップ」をクリックします。

Image14


すると画面上にQRコードの表示がされますので、このQRコードを

Authenticator アプリで読み取る必要があります。

Image19

Apple Store または Google Play 経由で「Microsoft Authenticator」を

インストールします。(今回、アプリのインストールは割愛します)

インストールしたAuthenticatorを起動後、画面右上の「+」をクリック

します。

Img_50441_2
「職場および会社のアカウント(Work or school account)」をクリック

します。

Img_5045
スキャンを求められますので、画面に表示されているQRコードを読み取る

アカウント情報が追加されます。

Img_50481


これでモバイルアプリ側の設定が完了です。


次回以降、Office 365ログイン時に、ID/PWを入力すると、Authenticator

に表示される6桁の確認コードを都度入力する動作となります。

これでAttack Simulatorを利用する準備が出来ましたので、スピアフィッ

シング攻撃のシミュレーションを実行したいと思います。


攻撃シミュレーターの詳細は以下も併せてご確認下さい。


攻撃 Simulator (Office 365)
https://support.office.com/ja-jp/article/%E6%94%BB%E6%92%83-Simulator-Office-365-da5845db-c578-4a41-b2cb-5a09689a551b?wt.mc_id=O365_Portal_MMaven

まず、Office 365管理ポータルにアクセスし、「管理センター」>「セキュ

リティ」を選択します。

Image1

「脅威の管理」>「攻撃シミュレーター」をクリックします。

Image3

スピアフィッシングの「攻撃の開始」をクリックします。

Image4_2

「Use Template」クリックします。

Image5_2

するとテスト用に「プレゼントの当選」「給与計算の更新」といった2つの

テンプレートが選択出来ますので、今回は「経費精算」を利用したいと

思います。

Image7


続いて、攻撃対象となるターゲットユーザーを指定して「次へ」をクリック

します。

Image12_2
実際に通知される差出人や件名、不審URLなどを指定して「次へ」をクリック

します。

Image13_2

必要に応じてメール文面等も加筆修正し、「次へ」をクリックします。

Image16

最後に「完了」をクリックします。

Image17

ここまでの手順でフィッシングメールがユーザーに通知された事になります。

それではTMCASによる処理の状態を見てみたいと思いますが、冒頭にも

お伝えしたように今回は無料評価版を利用した内容となりますので

手動検索のみが利用可能となっています。

そのため、今回はTMCAS管理コンソールから「手動検索」を実施し、

フィッシングメールがどのように処理されるかを確認したいと思います。

TMCAS管理コンソールにアクセス、「高度な脅威対策」に移動します。

Image1_2

「初期設定のExchange ポリシー - 高度な脅威対策」の左端にあるチェック

を付け「手動検索」をクリックします。

Image3_2

検索内容を確認し、ここでは既定のままで[実行]をクリックします。

Image4_3

OWAからメールボックスにアクセスしてみると、フィッシングメールは

すでに削除されており、またTMCASが削除処理を実行した旨のシステム

メッセージが表示されています。


Mail

今度は、TMCASの管理コンソールから検知ログの状態を確認してみま

しょう。

すると、 ログにもWebレピュテーションによってメールメッセージが削除

処理されたログが確認出来ました。

Log
今回は評価版という事もあり、手動検索で検知・処理される様子を紹介し

ましたが製品版であればメール受信後すぐにリアルタイム検索で検知される

動作となります。

このようにTMCASは、Office365 のセキュリティ と組み合わせて様々な

脅威に対して対処可能である事がお分かり頂けたと思います


2回にわたってTMCASの解説をしてきましたが如何でしたでしょうか。

是非、TMCASでより安全に快適な Office 365 環境を実現頂ければと

思います。

今回も最後まで読んで頂きありがとうございました!

記事投稿者:津久井

2018/06/05

Office365 と Trend Micro Cloud App Security でより安全なクラウドへ(前編)

皆さん、こんにちわ。

今回の記事は、Office365を既に利用されている方、Office 365導入を検討

されている方を対象にお話させて頂きたいと思います

皆さんが Office365 や Azure 等のクラウドサービスを導入するにあたって

まず最初に懸念すること、それはやはりセキュリティではないかと思います。

そこで今回はOffice365をより安全に使って頂くためのソリューション

「Trend Micro Cloud App Security(以下、TMCAS)」

をご紹介したいと思います。

「あれ、待てよ、Cloud App Security ってたしか Office 365 でも

付いてなかったっけ」

とお気づきの方もいらっしゃると思います。

たしかに Offiice365 E5プランにおいて Cloud App Security という

機能が提供されています。


更に Office 365 だけでなく Azure を含めたMicrosoft Cloud App

Security という製品も存在しています。

両者の違いや機能について語り始めてしまうと、それだけでおなか一杯に

なってしまいそうですので、詳細については↓を参考にして頂ければと

思います。

https://docs.microsoft.com/ja-jp/cloud-app-security/editions-cloud-app-security-o365

上記からもわかるようにMicrosoft さん、かなりセキュリティに注力されて

いることがわかると思います。

それもそうですよね、Office365をはじめとしてクラウドはインターネットの

危険にさらされているわけですから、クラウドを提供する会社が注力しない

わけがないですね。

ちなみにセキュリティに注力されているMicrosoftさんが昔から提言されて

いるセキュリティ原則をご存知でしょうか。

それは「多層防御」です。

様々なプロセスにおいていくつもの予防線を張ることで容易には侵入させ

ないシステムを作り上げるという事です。

最近では標的型メールなど侵入自体を防ぐことは厳しいので、侵入されて

からのセキュリティをどうするかといったマインドセットが重要となり

ますが、それでもやはり無防備に侵入を許すわけにはいかないですね。

この多層防御という観点からいうと、Microsoftさんのセキュリティ

ロジックだけでなく、他ベンダーのセキュリティロジックをミックス

する事によって、更なる堅牢性を高められるのではないかと思います。

ちょっと前置きが長くなってしまいましたが、それでは改めてトレンド

マイクロさんの Cloud App Security の内容について触れていきたいと

思います。

Trend Micro Cloud App Securityは、Office 365のExchange、

SharePoint、OneDriveのメールおよびファイル保護を目的とした

トレンドマイクロ社のクラウドサービスです。

※Office 365 以外のクラウドサービス(Google ドライブ、Dropbox、Box)も

 対応しています。

TMCAS の導入のメリットは、わざわざTMCAS用のサーバーを用意する

必要が無い点と、Office365とのAPI連携によってネットワーク経路の

変更を行う必要が無いという点です。

Cas91

従来のセキュリティソリューションとしては、Office365とインターネットの

経路上にセキュリティ製品を配置するパターン、つまりゲートウェイ機器の

ように配置し、Office365 および インターネットからの経路設定を変更して

導入するパターンが一般的かと思います。

これに対してTMCASの場合は、API型と呼ばれ、Office365とバッググラ

ウンドで処理を行う仕組みを採用しています。

そのため、ゲートウェイ型のように経路変更のためにDNSレコードの書き

換えルーティング変更等が一切不要となります。

Office365 管理者の観点からは、TMCAS導入に伴って、ネットワーク回り

調整も不要ですので、管理者に余計な負担をかけず容易に導入が可能です。


Cas02

さらに TMCAS 自体も以下のような「機械学習」や「サンドボックス」と

いった機能を駆使して未知の脅威に備える事が可能です。

Cas03



ルーティングが不要となるというメリットがある一方で、ご留意頂きたい

点として、TMCASの保護対象は、あくまでメールボックスに到達した

メッセージならびに SharePoint/OneDrive 上にファイルがアップ

ロードされたタイミングで検索/処理が実行されるということです。



そのため、外部へのメール送信時の動作として、送信済みアイテムのメールが

検索/処理されますが、外部へのメール送信をブロックすることはできません。

この部分に関しては、Office 365 標準の Exchange Online Protection

を利用して頂ければと思います。

Office365 における保護の役割は大きく以下の2つです。

・高度な脅威対策
 従来のシグネチャーベースのウィルス対策をはじめ、サンドボックス技術を

 利用した未知の脅威に対する保護、およびWeb、ファイルレピュテーション

 機能を提供します。

・情報漏洩対策
 データ損失保護(DLP)といった機能で、個人情報や機密情報の流出の保護

特に TMCAS でイチオシしたい機能は、情報漏洩対策の「マイナンバー」に

対するDLP機能を持っていることです。

Office 365 においてもDLPという機能を提供していますが、この

「マイナンバー」に関しては現状は未対応です。

この日本固有の「マイナンバー」をはじめとして、個人情報保護法などに

対応出来ているところがトレンドマイクロさんの柔軟性を感じますね!

あとは、導入がとってもシンプルで簡単です。

TMCASの導入の容易さの背景には、先ほども申し上げたようにOffice 365 と

API経由でTMCASが連携して動く点にあります。

TMCASはOffice365と同じように、30日の無料評価版を試していただける

ようになっていますので、この後、評価導入のステップをご紹介しますが、

とても簡単だなと実感頂けると思います。

それでは、実際に評価導入のステップをご紹介していきたいと思います。

※評価頂くための Office365環境をお持ちでない方は、以下のサイトに

 アクセスし、事前にOffice365評価版への登録をお願い致します。

 https://aka.ms/e5trial

まずはこちらのサイトから評価版の登録をしていきます。

https://www.trendmicro.com/ja_jp/business/products/user-protection/sps/email-and-collaboration/cloud-app-security.html

「体験版」をクリックします。
Image1_2

体験版の申し込み画面が表示されますので、必要な情報を入力します。
Image2

登録の最後は、TMCASの管理コンソールにアクセスするためのアカウントを

登録し、「体験版の利用を開始する」をクリックします。
Image3

登録完了画面が表示されますので、画面中央にある製品コンソールのURLを

クリックします。
Image41


Image9

初回ログイン時に、TMCASと連携するサービスを選択する画面が表示され

ます。ここではOffice 365を選択し、OKをクリックします。
Image11

つづいて、連携に必要となるOffice 365管理者のアカウント情報を

入力します。
Image12

アカウント入力後、Office 365で保護すべきサービスを選択します。

今回は、Exchange,SharePoint,OneDrive の3つすべてを選択して

次へ進みます。
Image17

TMCASとOffice365との連携処理が開始され、完了すると管理コンソールの

ダッシュボード等が表示されます。
Image19


今回の投稿はここまでとなります。


導入のステップ、如何でしたでしょうか?

次回は後編として、管理コンソールから利用可能な機能や、TMCASが

ウィルス等の脅威に対してどのように保護するかを、Office365の機能

にも触れながらご紹介していきたいと思います。


最後に余談となりますが、今回ご紹介した導入ステップの画面ショットの

各画面に緑の枠線が表示されていたと思いますがこれは Windows 標準の

「問題ステップ記録ツール(以下、PSR)」というものを利用して取得して

いたためです。


よく○○shotといったサードパーティツールが存在しますが、Windows標準

でもこのようなツールが提供されています。

意外と歴史は古くWindows Vistaから導入された機能で、Windows10に

おいても利用可能です。



PSRの本来の目的は「問題が発生した操作を記録する」もので、Microsoft

サポートの方とやり取りする中で、このPSRの結果を求められる事もよく

あります。

そんなPSRですが、作業のエビデンスを取得する際、○○shot などのアプリ

実行が禁止されている環境においても簡単に画面ショットが取得可能です。

このツールの使い方について、以下の情報などを参考に試して頂ければと

思います。

問題を再現する手順の記録
https://support.microsoft.com/ja-jp/help/22878/windows-10-record-steps

Windows ステップ記録ツール(psr)のススメ
https://qiita.com/gzock/items/1c934d6577eec3b7f7ff


今回も最後まで読んで頂きありがとうございました!


記事投稿者:津久井

2018/05/25

Azure 上で SharePoint Server 2016 をオフラインインストールしてみよう!(後編)

今回は「Azure 上で SharePoint Server 2016 オフラインインストールしてみよう!」

後編となります。

前回の投稿はこちらです。

https://blogs.networld.co.jp/main/2018/05/azure-sharepoin-caa6.html

後編は引き続き以下の導入ステップ 4~6 についてご紹介していきたいと思います。

 

1.Azure クイックスタートテンプレートによるAD 仮想マシンの展開

2.ギャラリーからのSQL Server 2016 仮想マシンの展開

3.WebPIを利用したWorkFlow Managerのオフラインインストール

4.SharePoint前提条件のオフラインインストール

5.SharePoint Server 2016 のオフラインインストール

6.Workflow Manager の初期設定と SharePoint Server 連携設定

 

4.    SharePoint前提条件のオフラインインストール

 

SharePoint導入に必要な前提条件はインストールCDの「prerequisiteinstaller.exe」

を実行する事で、SharePointの前提となるソフトウェアを自動でインストールします。

 

こちらも通常ですと Workflow Manager と同様にインターネットに繋がっている事を

前提としています。

 

インターネット接続出来ないオフライン環境でインストールするには、前提のコンポー

ネントを個別にダウンロードする必要があります。

 

以下のSharePointサポートチームブログに個別にダウンロードが必要な記載されて

おりますので、こちらからダウンロードしたファイルをインストールCDの

「prerequisiteinstallerfiles」のフォルダにコピーします。

 

※インストールCDの中身は事前にサーバーの任意の場所にコピーしておいてください。

 

SharePoint Server 2016 のオフライン インストール

https://blogs.technet.microsoft.com/sharepoint_support/2016/04/05/sharepoint
-server-2016-%E3%81%AE%E3%82%AA%E3%83%95%E3%83%A9%E3%82%A4%E
3%83%B3-%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%
BC%E3%83%AB/

 

今回はFドライブのSP2016ファルダ配下にインストールCDのコピー先としましたので

「PrerequisiteInstaller.Arguments.txt」は以下の記載となります。

/sqlncli:"F:\SP2016\prerequisiteinstallerfiles\sqlncli.msi" /ODBC:"F:\SP2016
\prerequisiteinstallerfiles\msodbcsql.msi" /Sync:"F:\SP2016
\prerequisiteinstallerfiles\synchronization.msi" /AppFabric:"F:\SP2016
\prerequisiteinstallerfiles\WindowsServerAppFabricSetup_x64.exe" /IDFX11:"F:\SP2016
\prerequisiteinstallerfiles\MicrosoftIdentityExtensions-64.msi" /MSIPCClient:"F:\SP2016
\prerequisiteinstallerfiles\setup_msipc_x64.exe" /WCFDataServices56:"F:\SP2016
\prerequisiteinstallerfiles\WcfDataServices.exe" /KB3092423:"F:\SP2016
\prerequisiteinstallerfiles\AppFabric-KB3092423-x64-ENU.exe" /MSVCRT11:"F:\SP2016
\prerequisiteinstallerfiles\vcredist_x64.exe" /MSVCRT14:"F:\SP2016
\prerequisiteinstallerfiles\vc_redist.x64.exe"

この「PrerequisiteInstaller.Arguments.txt」 を 「PrerequisiteInstaller.exe

同じ場所に配置し、実行します。

 

参考:実行時にテキストファイルの記載に誤りがあるとエラー画面が表示されるので、

ログファイルを確認し、テキストファイルに誤りがあれば修正してください

 

Image31 

5.    SharePoint Server 2016 のインストール

前提条件のインストールが完了すれば、あとはSharePointの通常のインストールの

ステップを進める形となります。

 

インストール手順に関しては以下のサイトで解説されていますので、ここでは手順の

ステップは割愛し、インストール・初期設定時のパラメーターを記載させて頂きます。

 

SharePoint Server 2016 を 1 台のサーバーにインストールする

https://docs.microsoft.com/ja-jp/sharepoint/install/install-sharepoint-server-2016-on-one-server

 

SharePoint 2016 のインストール

設定項目

既定値

参考設定値

備考

ファイルの場所

(SharePoint

2016)

C:\Program

Files\Microsoft Office

Servers

 既定値と同じ  

ファイルの場所

(検索インデックス ファイル)

C:\Program

Files\Microsoft Office

Servers\16.0\Data

 既定値と同じ  

SharePoint 製品構成ウィザードの実行

設定項目

既定値

設定値

備考

サーバーファームへの接続

●既存のサーバー ファームへの接続

○新しいサーバー ファームの作成

○既存のサーバー ファームへの接続

●新しいサーバー ファームの作成

 

データベース サーバー

(空白)

<データベースサーバー名>

 

データベース名

SharePoint_Config

   

ユーザー名

(空白)

SPS\Spfarm

 

パスワード

(空白)

********

 

パスフレーズ

(空白)

********

 

サーバーの役割

○フロントエンド

○フロントエンド

 

 

○アプリケーション

○分散キャッシュ

○検索

○ユーザー設定

○単一サーバー ファーム

○アプリケーション

○分散キャッシュ

○検索

○ユーザー設定

●単一サーバー ファーム

 

ポート番号

□ポート番号を指定する

■ポート番号を指定する

55555

 

セキュリティ設定の構成

○NTLM

○ネゴシエート

(Kerberos)

●NTLM

○ネゴシエート

(Kerberos)

 

ファーム構成ウィザードの実行

設定項目

既定値

設定値

備考

サービス アカウント

○既存の管理アカウントを使用する

●新しい管理アカウントを作成する

ユーザー名

(空白)   パスワード

(空白)

○既存の管理アカウントを使用する

●新しい管理アカウントを作成する

ユーザー名

SPS\Spsvc パスワード

********

 

サービス アプリケーション

App Management

Service

Business Data

Connectivity Service

Lotus Notes Connector

Machine Translation

Service

Managed Metadata

Service

PerformancePoint

Service Application

■PowerPoint Conversion

Service Application

■Project Server Service

Application

■Search Service

Application

■Secure Store Service

■State Service

■Usage and Health data collection

■User Profile Service

Application

■Visio Graphics Service

■Word Automation

Services

■Workflow Service

Application

   

サービス

     

サイト コレクションのタイトル

(空白)

トップ

 

URL

/

   

テンプレートの選択

チーム サイト

   

   

  6. Workflow Manager 初期設定とSharePoint 連携設定

 

前回投稿のステップ 3 でインストールしたWorkflow Manager の初期設定として

Workflow Manager ファームの作成を行います。

 

ファームの作成に関しては、下記の情報を参考にして頂ければと思いますが

簡単に設定ウィザードの流れをご説明していきます。

 

新しいファームの作成

https://msdn.microsoft.com/ja-jp/library/jj193514(v=azure.10).aspx

 

Workflow Manager 構成ウィザードが起動します。

[既定の設定を使用して Workflow Manager を構成する(推奨)] をクリックします。 

Image7

[新しいファームの構成] 画面で下記設定を行います。[→]をクリックします。

SQL Server インスタンス

SQL Server 名 (FQDN)

認証

Windows 認証 (デフォルト)

サービス アカウント名

AccountName@DomainName

このコンピューターの HTTP によるWorkflow 管理を許可する

チェックあり (デフォルトはチェック無し)

このコンピューターのファイアウォールルールを有効にする

チェックあり (デフォルト)

証明書生成キー

任意のキー

メモ:既定では、HTTPSを使用して通信します。そのため、HTTPによるワークフロー

管理を許可する場合は、[このコンピューターの HTTP による Workflow 管理を

許可する] チェックボックスをオンにします。

Image9

[概要] 画面で構成を確認します。[✔]をクリックします。

Image12

Image13 構成が完了したことを確認します。

Image16

下記画面が表示されたらインストールは完了です。

Image18

[完了] をクリックします。

         

最後のステップは、SharePoint サーバーと Workflow Manager の連携設定を行います。

 

連携方法としてはHTTPSまたはHTTP接続での連携となりますが、今回はHTTP接続を

前提としたステップとなります。

 

設定方法としては、SharePoint 管理シェルを利用して以下のコマンドを実行します。

 

Register-SPWorkflowService –SPSite "http://(SharePointサーバー)" –WorkflowHostUri http://(Workflow Managerサーバー):12291–AllowOAuthHttp

 

実行後、SharePoint サーバーの全体管理にアクセス、アプリケーション構成の管理>サービス アプリケーション>サービス アプリケーションの管理>Workflow Service Applicationを選択します。

Image19

 

「ワークフローは接続されています」が表示されていれば設定は完了です。

Image20_2

今回は Azure クイックスタートテンプレートを利用して、SharePoint Server 2016

簡易評価環境をオフラインインストールで構築するステップを紹介しました。

Azure上で敢えてオフラインインストールというだいぶニッチな内容ではありましたが

オンプレミス環境でも同様の手順で環境構築にも活かせますので、是非試して頂ければ

と思います。

今回はSharePoint環境構築のみとなりますが、ワークフロー機能等を具体的な設定方法

などは以下のガイドが公開されていますのでこちらを参考して頂ければと思います。

 

Microsoft SharePoint Server 2013 ワークフロー活用ガイド

http://download.microsoft.com/download/A/F/B/AFB0C8F4-6AAA-44E8-A119-C755BA7831DA/SharePoint2013_Workflow_final.pdf

 

最後に弊社から改めてご案内をさせて下さい。

 

前回の投稿でもご案内しておりますが、弊社はMicrosoftのCSPパートナー契約を結んで
います。

 

CSP(Cloud Solution Provider)とはOffice 365やAzureなどマイクロソフトの

クラウドサービスを月額課金方式で再販する新しい販売モデルです。

 

Image48

 

クラウドを中心としたビジネスにおいて継続的に利益を上げるには、安定した

月額課金型ビジネスを通じてお客様との中長期的な関係を構築する必要があります。

 

CSPはこうしたビジネス環境の変化に対応し、パートナー様が他社との差別化を図り、

顧客ニーズに沿ったパートナー様独自の付加価値を提供することによって収益性の

向上と新たなビジネスチャンスを創出するためのプログラムとなっています。

 

弊社ではCSPリセラー様を募集しており、CSPリセラー様への各種支援策を実施中です。

Office 365やAzureの月額課金販売に興味があり、導入時の技術支援が必要なパートナー様は

是非弊社営業またはms-solution@networld.co.jpまでご相談ください。

Image49

今回も最後までご覧いただきましてありがとうございました!

投稿者:津久井

2018/05/18

Azure 上で SharePoint Server 2016 をオフラインインストールしてみよう!(前編)

 

本記事は、「Microsoft Azure を使い始めた方」「SharePoint Server を評価検証したい 方」向けの内容となります。

 

今回のお題であるSharePoint Server 2016インストールですが、ただ単純にインストール

するのでは面白味に欠けるかなという事で、今回はインターネットに繋がっていない

状態(オフライン)でSharePointをインストールする方法をお伝えしたいと思います。

 

「なぜわざわざオフラインでするのか? しかもAzure上なのに?」

 

とお思いの方もいらっしゃると思いますが、お客様の中にはセキュリティポリシー上

インターネットへの通信が許容されないという環境もあるかと思います。

 

基本的なSharePointのインストールに関しては以下のSharePointチームブログ

Microsoft MVPの方も情報提供されていますが、こちらの内容を参考にしつつ

進めていきたいと思います。

 

SharePoint Server 2016 単一サーバー (検証) 環境構成メモ

https://crieilluminate.wordpress.com/2016/09/29/sharepoint-server-2016-config/

 

SharePoint Server 2016 のオフライン インストール

https://blogs.technet.microsoft.com/sharepoint_support/2016/04/05/sharepoint-server-2016-%E3%81%AE%E3%82%AA%E3%83%95%E3%83%A9%E3%82%A4%E3%83%B3-%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB/

 

今回のシステム構成は以下となります。

Image1

 

SharePoint2016は、スタンドアロンでSQLサーバーとSharePointサーバーの同居構成となり

もっともシンプルな構成です。

 

 

導入ステップとしては以下の流れで進めていきたいと思います。

1.Azure クイックスタートテンプレートによるAD 仮想マシンの展開

2.ギャラリーからのSQL Server 2016 仮想マシンの展開

3.WebPIを利用したWorkFlow Managerのオフラインインストール

4.SharePoint前提条件のオフラインインストール

5.SharePoint Server 2016 のオフラインインストール

6.Workflow Manager の初期設定と SharePoint Server 連携設定

 

※Azure 仮想マシンのOS日本語化手順は割愛しています。

今回は上記ステップのうち、前半のステップ1~3について触れていきます。

それでは早速見ていきましょう。

 

1.    Azure クイックスタートテンプレートによるAD 仮想マシンの展開

今回はAzure上に新しいリソースグループを作成し、ADとなる仮想マシン1台を構成します。

 

またADサーバーの仮想マシンはAzure クイックスタートテンプレートというものを利用して

展開したいと思います。

(本題はSharePointですので少しでも手抜きしたいという(笑))

 

クイックスタートテンプレートは、複数の仮想マシンを展開するための設定情報が

コーディングされています。

 

様々なパターンのテンプレートが公開されており、このクイックスタートテンプレートを

利用する事によって仮想マシンを効率よく展開可能です。

 

それではまず以下のURLにアクセスします。

 

https://azure.microsoft.com/ja-jp/resources/templates/

 

画面上部に検索窓が表示されていますので、ここに検索キーワードとして、

 

「new AD Forest」と入力してみます。

 

すると7件がヒットしました。

 

このテンプレートがよさそうですので、こちらを選択します。

 

Image2

 

「Azureへのデプロイ」をクリックします。

 Image3

Azure ポータル画面に遷移しますので、必須のパラメーターを入力して「購入」をクリックします。

Image4_2

 

テンプレートが展開されますので、しばらく待ちます。

 

ちなみに今回のテンプレートではAzure VMの仮想マシン名やVMインスタンスのサイズは

問われませんでしたが、出来上がった仮想マシンは、「adVM」という名でVMサイズは

「D2V2 Standard」 が選択されていました。

 

この辺りの調整は、テンプレートのJSONファイルの記述を修正することで、カスタマイズ

可能です。

 

Image5_2

今回のテンプレート展開で作成された仮想ネットワークにはDNSサーバーとして

ADサーバーのプライベートIPが設定済みの状態となっています。

 

この後作成するSharePointのサーバーもこの仮想ネットワークを使用する事で予め

ADサーバーをDNSとして構成する事が可能です。

 

以上、ここまででADサーバーとSharePointが参加するドメイン環境が整いました。

 

次のステップとして SharePoint サーバーの導入に取り掛かりたいと思います。

 

2.    ギャラリーからのSQL Server 2016 仮想マシンの展開

 

SharePoint Serverはデータの格納先としてSQL Serverを利用しています。

 

今回も時間短縮のためAzureのギャラリーにあるSQL 2016VMを利用してSharePointの

ベースとなるSQL導入済みの仮想マシンを作成したいと思います。

 

Azure 管理ポータルで先ほど作成したリソースグループに移動し、「追加」をクリック

します。

 

Image6_2

 

ギャラリー画面で、SQL Server 2016 SP1 と入力し検索します。

 

Image7_2

 

検索結果から、[SQL Server 2016 SP1 Standard on Windows Server 2016]を

選択し「作成」をクリックします。

 

SQLVMに関するパラメーターを入力します。

 

Image8_2

 

仮想マシンが15分~20分程度で出来上がるので、しばらく待ちます。

 

 

仮想マシン展開が完了したら、仮想マシンに接続しドメイン参加を行います。

今回はsps.localというドメインに参加します。

 

最後に仮想マシンからインターネットへの通信をオフラインとするため、仮想マシンの

ネットワーク設定で「送信ポートの規則」で下記のルールを追加します。  

 

Image101_2

 

次のステップは、Workflow Manager サーバーのインストールとなるのですが、

あまり馴染みの無いコンポーネントかも知れませんので簡単にご紹介します。

 

Workflow Managerとは SharePoint Server 2013から提供されたワークフロー

専用サーバーとしての役割を担っています。

 

SharePoint Server 単体でももちろんSharePoint 2010以前の標準的なワークフロー

機能は利用できますが、Workflow Managerを導入する事でSharePoint 2013 以降で

実装された複雑な条件分岐をもつワークフローを作成可能となり、企業のニーズに

マッチしたワークフローを実現出来ます。

 

このWorkflow Managerですが、通常Webプラットフォームインストーラー(WebPI)

と呼ばれるインストーラーを利用してインターネットから必要なコンポーネントを

ダウンロードしながら、インストールを行うツールとなります。

 

今回はこのWorkflow Managerのインストール以降の手順に関しても、オフライン縛り

という前提で進めていきたいと思います。

3.    WebPIを利用したWorkFlow Managerのオフラインインストール

 

Workflow Managerのオフラインインストール手順は以下のKBに沿った形となります。

 

Workflow Manager 1.0 のオフライン インストール手順

https://msdn.microsoft.com/ja-jp/library/jj906604(v=azure.10).aspx

 

ただし、上記はWindows Server 2012R2を前提としたステップとなっており

Windows Server 2016にインストールする場合はひと手間必要となります。

 

ひと手間というのは、

 

Windows Server 2016 に対応したWorkflow Manager累積アップデート4(CU4)以降

 

をインストールする必要があります。

 

Workflow Manager 1.0 Now Supported on Windows Server 2016 with CU4

https://blogs.msdn.microsoft.com/workflowteam/2017/07/25/workflow-manager-1-0-now-supported-on-windows-server-2016-with-cu4/

 

現時点での最新パッチバージョンはCU5となりますので、今回はCU5を適用していきます。

 

ここで一旦手順を整理すると

 

  1. Web PI のインストール

(インターネット接続可能な端末を利用)

 

  1. Web PIでのWorkflow Manager必要コンポーネントのダウンロード (インターネット接続可能な端末を利用)

 

  1. Web PIでのWorkflow Manager Refresh インストール (手順2以降は、SharePoint サーバー上で実行)

 

  1. Service Bus Updateインストール
  2. Workflow Manager CU5のインストール

 

※手順3は、Workflow Manager CU5 の前提を満たすService Busのアップデート

 

 

それでは上記ステップを順番に進めていきます。

 

  1. Web PI のインストール (インターネット接続可能な端末で実行)

 

必要コンポーネントをダウンロードするため、インターネット接続可能な任意の端末を準備します。

 

以下から Web Platform Installer をダウンロードし、任意の場所に保存します。

 

Web Platform Installer 5.0

https://www.microsoft.com/web/downloads/platform.aspx

保存後、ウィザードに従ってインストールします。

Image11

Image12

このWeb PI インストールファイルはSharePointサーバー上でも再度利用します。

 

  1. Web PI コマンドラインを利用したWorkflow Managerコンポーネントのダウンロード (インターネット接続可能な端末で実行)

 

コマンドプロンプトを起動し、以下のコマンドを実行します。

c:\Program Files\Microsoft\Web Platform Installer>webpicmd /offline /Products:WorkflowManagerRefresh /Path:c:\WorkflowManagerFiles

ダウンロードが開始されます。

 

Image141_2

画面が閉じるとダウンロードが完了します。

 

指定したフォルダにインストールファイルがダウンロードされている事が確認出来ます。

 

Image15

このダウンロードしたファイルをSharePointサーバーにコピーしておきます。

  1. Web PIのインストール (SharePoint サーバー上で実行)

 

手順1と同様にWeb PIをインストールします。

 

  1. Web PIでのWorkflow Manager Refresh インストール (SharePoint サーバー上で実行)

 

手順2でダウンロードしたファイルをSharePointサーバーにコピーします。

今回はC:\WorkFlowManagerFiles にコピーしています。

 

以下のコマンドを実行します。

c:\Program Files\Microsoft\Web Platform Installer>webpicmd /Install /Products:WorkflowManagerRefresh /Path:c:\WorkflowManagerFiles/feeds/latest/webproductlist.xml

 

Image16

 

同意を求めてきますので、「Y」と入力します。

Image17

 

インストールが開始されます。

Image18

 

Image19

インストール完了と同時にWorkflow Managerの構成ウィザードが起動しますが、ここでは×印をクリックして画面を閉じます。

 

Image20

  1. Service Bus Updateインストール

続いてService Bus Updateをインストールします。

   インストールに必要なファイルは、Web PIを介してダウンロード済みなのですが、

手順4では 自動でインストールされません。(Workflow Manager CU2以前は適用が不要なため)

 

   そのため、手動でインストールを行います。

   手順はウィザードに従ってインストールを実行します。

 

Image21

 

Image22

 

Image23

 

  1. Workflow Manager CU5のインストール

こちらも個別にダウンロードしたファイルしたものをインストールします。

   ステップとしてもウィザードに従って行うのみとなります。

 

Image24

 

Image25

Image26

Image27

何度かコマンドプロンプト画面が表示された後、インストールが完了します。

 Image28

これでWorkflow Managerのインストールが完了しました。

 

この後は SharePoint Server本体のインストールを進めていく事になりますが

今回の投稿はここまでとなります。

次回は引き続き以下のステップをご紹介していきます。

 

4.SharePoint前提条件のオフラインインストール

5.SharePoint Server 2016 のオフラインインストール

6.Workflow Manager の初期設定と SharePoint Server 連携設定

 

最後に弊社から1点ご案内をさせて下さい。

 

今回、Microsoft Azureに関連した内容をご紹介しましたが、弊社はMicrosoftの

CSPパートナー契約を結んでいます。

 

CSP(Cloud Solution Provider)とはOffice 365やAzureなどマイクロソフトの

クラウドサービスを月額課金方式で再販する新しい販売モデルです。

 

Image48

 

国内のIT投資額が伸び悩む中、最近の調査ではクラウドサービスは2ケタ成長を続け、

今後数年間はこのトレンドが続くと言われています。

 

また、80%以上のお客様が次期システムはクラウドを優先して検討すると言われており、

今後パートナー様が安定した成長を続けるためにはクラウドへの対応が重要になります。

 

このクラウドを中心としたビジネスにおいて継続的に利益を上げるには、安定した

月額課金型ビジネスを通じてお客様との中長期的な関係を構築する必要があります。

 

CSPはこうしたビジネス環境の変化に対応し、パートナー様が他社との差別化を図り、

顧客ニーズに沿ったパートナー様独自の付加価値を提供することによって収益性の

向上と新たなビジネスチャンスを創出するためのプログラムとなっています。

 

弊社ではCSPリセラー様を募集しており、CSPリセラー様への各種支援策を実施中です。

Office 365やAzureの月額課金販売に興味があり、導入時の技術支援が必要なパートナー様は

是非弊社営業またはms-solution@networld.co.jpまでご相談ください。

Image49

最後までご覧いただきましてありがとうございました!

投稿者:津久井

2018/02/14

Veeamで物理サーバもまとめてバックアップできるんだ。こんなに嬉しいことは無い。

時間が経つのは早いもので、今年も2月中旬になってしまいました。昨年の売り上げが前年比36%増と絶好調だったVeeam Softwareですが、昨年末にはVeeam Backup & Replication(以下、VBR) 9.5の最新アップデートであるUpdate3をリリースしております!

※Release Notes for Veeam Backup & Replication 9.5 Update 3

https://www.veeam.com/kb2353

昨年5月の年次イベントであるVeeamON 2017において、次期バージョン(v10)で実装する新機能を発表しておりましたが、v10を待ちきれないユーザーの気持ちを忖度し(?)、VBR 9.5 Update 3ではv10で実装する予定だったいくつかの機能を先行して実装しています。

VBR 9.5 Update3ではIBM Storwizeのストレージスナップショットとの連携やvCloud Director 9.0対応、VMware Cloud on AWSサポート、Data Domain OS 6.1のサポート、LTO-8テープ対応などなど多くの機能追加や機能拡張が行われておりますが、特に注目したいのがエージェント管理機能です。そこで、今回はエージェント製品についてご紹介しましょう。


■エージェント製品とは?

仮想環境のバックアップで有名なVeeamですが、実はVeeam Agent for Microsoft WindowsVeeam Agent for Linuxといった物理サーバをバックアップするための製品もあります。エージェント製品はバックアップ対象サーバにエージェントソフトウェアをインストールし、オンラインでディスクイメージをバックアップする製品です。

 

Agent01_8


システムリカバリは専用のリカバリメディアからサーバを起動してリストアするだけで、簡単にサーバを復旧することができることからシステムバックアップ用途でも多く使われています。 

Agent02_8


■VBRとの連携

エージェント製品はVBRのオプションではなく、単体で動作する別製品です。これまで、エージェント製品のバックアップ先としてVBRのリポジトリを利用する部分的な連携機能はありましたが、バックアップジョブの作成やステータスの確認は、それぞれの製品の管理コンソールから行うため、管理は別々になっていました。

しかし、VBR9.5 Update 3からは、VBRの管理コンソールからVeeam Agent for Microsoft Windows(v2.1)やVeeam Agent for Linux(v2.0)のエージェントを管理でき、バックアップジョブの作成やステータスの確認が行えるようになりました。エージェント製品がVBRと別製品であることは変わりませんが、このエージェント製品との統合により、仮想環境も物理環境も纏めて1つのコンソールから纏めて管理することが可能です。

 

Agent03_10


■エージェント統合のメリット

仮想環境が当たり前の時代とは言え、どうしても物理サーバは残ってしまうものです。そのような時に、仮想環境をVBRでバックアップしつつ、物理環境はエージェント製品でバックアップすることで、1つの管理コンソールから仮想も物理も纏めてバックアップの管理ができるだけでも素晴らしいのですが、Windowsでは更にメリットがあります。

実は、VBRの管理サーバは構成情報をバックアップする機能はありますが、残念ながら、管理サーバ自身のシステムバックアップ機能はありません。サーバに障害が発生した場合、仮想マシンをリストアできる状態に戻すには、ハードウェアを修理後に①OSインストール・設定→②VBRインストール→③VBR構成情報のリストアという手順を踏む必要があります。

しかし、Veeam Agent for Microsoft WindowsでVBRの管理サーバをバックアップしておけば、OSやVBRを再インストールすることなく、リカバリメディアからサーバを起動してバックアップデータをリストアするだけで簡単に素早くVBR管理サーバを復旧することができてしまうのです。

Agent05_2

更に、仮想環境としてHyper-Vをご利用の場合にはVBRでHyper-V仮想マシンをバックアップし、Veeam Agent for Microsoft WindowsでHyper-VホストをバックアップすることでHyper-Vのホストもゲストも纏めて完璧に保護できます。Hyper-VのバックアップでVBRを検討のお客様は、是非、エージェント製品も一緒にご検討いただければ幸いです。

Agent06_2


今年のVeeamは、待望のVBR新バージョン(v10)は勿論、Nutanix AHV用バックアップ製品、AWS用バックアップ製品など新製品を続々とリリースしていきますので、今年もVeeamにご期待ください!それでは、また。

【参考情報】

担当:臼井 

2017/08/23

HCIとパフォーマンス計測の美学 ー パート2 ー Microsoft SQL Server

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Technical Marketing EngineerであるAndy Daniel氏によるものです。原文を参照したい方はHCI and the Art of Performance Measurement - Part II - Microsoft SQL Serverをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig271

本シリーズのパート1で、Enterprise Strategy Group(ESG)と共同で行った、Nutanixエンタープライズクラウドプラットフォーム上での4つのエンタープライズクラスでミッションクリティカルなアプリケーションのワークロードについてのパフォーマンスの一貫性、予測性、そして拡張性についての背景を共有いたしました。他のベンダーが公開しているような人工的に生成された単純なI/Oを用いる「英雄の数字」とは異なり、我々は業界の標準となるアプリケーション検証ツールを利用して、現実的なワークロードを使うことにフォーカスしていたことを思い出して下さい。パート2では、我々はMicrosoft SQL Serverを利用した検証について、更に奥深く分け入りたいと思います。

検証のためのワークロードを選ぶ際に我々はデータとお客様からのフィードバックに大きく依存しています。SQL Serverは最も展開されているエンタープライズ・アプリケーションのリストのトップにおり、これは大した驚きでは無いでしょう。様々な場面で利用されていますから、そのパフォーマンスの要件も幅広いものとなります。ですから、検証のためにリファレンスとしての標準が必要となります。幸い、オンライントランザクション処理(OLTP)のような一般的なデータベースのワークロードのための優れたツールが開発されており、検証のパラメーターとそれがどのように実環境のワークロードとして適応されるのかを理解していればその実行はさほど難しいものではありません。最終的にはQuestのベンチマークファクトリーを利用することにし、更に業界標準のTPC-Eワークロードを利用することにしました。Questのドキュメントに検証のためのTPC自体の説明書きがあります:

「TPC-Eベンチマークはデータベースを証券ファームのお客様が利用することをモデルとしており、取引や会計審査、市場調査などのトランザクションを生成します。証券ファームは金融市場とやり取りし、お客様の代わりにオーダーを実行し、対応する金融情報を更新します。

このベンチマークは「拡張性」があります。つまり、証券ファームの顧客数は証券ファーム毎に様々に定義でき、ビジネスの規模はそれに応じて変化するのです。このベンチマークではベンチマーク内で実行されるトランザクションの混合具合も定義する必要があります。TPC-Eの計測は毎秒のドランザクション数(tps - tranaction per second)で与えられます。この値はサーバが一定の期間内でどれだけの取引結果のトランザクションを実行できたかという値となります。」

4台のWindows Server 2012 R2の仮想マシンで、SQL Server2016を稼働させた(物理ノードあたり1つずつ)後、我々はNutanix上におけるアプリケーションのベストプラクティスを参照して適切に構成を行いました。SQL Serverのための手引にはデータベースを作成する際に1つ以上のデータファイルを作成し、それぞれのデータファイルを別々のおライブへ割り当てます。完全な詳細についてはMicrosoft SQL Server Best Practices Guideをご参照下さい。オールフラッシュのNutanixクラスタが適切に構成されているため、OLTPデータベースの検証は大抵はCPUによって決まります。我々はホストのCPUに適切な余力を残しながら、仮想マシンに適切なvCPUの構成を入れることに重点的にフォーカスして、最大の毎秒のトランザクション数が一貫して提供ができるようにしました。ホストのCPUの利用率はほとんどの本稼働系システムの場合で最大でも80%であると考え、この閾値を下回ることが無いように検証をチューニングしました。

OLTPデータベースを検証する際には様々な検証構成のパラメーターがあり、これが結果に大きく影響します。それらのうちの一つがデータベースのサイズであり、ベンチマークファクトリーでは「scale factor」として設定できます。非常に小さなデータベースを使って検証することでtpsのスコアを釣り上げることもできましたが、我々は現実的なサイズである300GB(scale-factorは32)をそれぞれのデータベースインスタンス毎に設定しました。データベースを完全利用するため、我々は最終的にはエージェント仮想マシンから各々のデータベースに対して80同時ユーザーで付加生成しました。テストのパラメーターとしては「no think time(考えている時間は加味しない)」を設定しています。

ハイパーコンバージドインフラストラクチャの検証においてパフォーマンスの拡張性は非常に重要です。ESGは特にOLTPのパフォーマンスの拡張性とより多くの仮想マシンとインスタンスをクラスタに追加した際のワークロードの分散に興味を持ちました。ですから、単一仮想マシンとSQLサーバインスタンスの最適な構成を決めるための様々な事前検証を終えた後、検証はそれぞれの仮想マシン数で実行されており(1から4)、仮想マシンとインスタンスを追加する毎に予測通りのパフォーマンスの拡張がなされることを確認しています。以下の画像で確認できるとおり、tpsがリニアに拡張されるだけでなく、平均トランザクション応答時間は低く、さらに特筆できるほどに安定しています。

Fig272

テストの結果、インスタンスあたりの毎秒のトランザクション数の総計は2,635~2,703と非常に狭い幅に収まっており、平均すると2,658です。ワークロードをスケールさせると、ESGは特にそのレスポンスタイムに感心していました。「ESGにとって更に印象的だったのは平均トランザクション応答時間でした、これは単なるストレージのレイテンシ以上のものだと考えることができますが、データベースの応答についてはコンピューティングが決定因子であるということがわかります。Nutanixのソリューションは一貫してワークロードが動作している4ノード全てで、0.031秒という超速のトランザクション時間を提供しているのです。」

パート1で言及したように、我々の検証はアプリケーションレベルでのパフォーマンスにフォーカスしていますが、その下のストレージのパフォーマンスに全てついても監視を行っており、平均のストレージのReadとWriteのレイテンシはそれぞれ0.95と1.59ミリ秒であったと記録されています。この低遅延によって、適切にCPUを稼働させることで最良の結果になるということがはっきりとわかります。この結果をより良い文脈で理解するために、これはOLTPでの検証だということを忘れてはいけません。すべての検証は継続的に行われたものです。言い方を変えるとターゲットとなるパフォーマンスは最高でかつ、少しの変動はありながらも安定的なものであるということです。もしも適切に構成されていればtpsの結果は狭い幅に「収まる」のであり、そのポイントに一貫してテストを停止するまであり続けます。これは実環境におけるパフォーマンスの能力を現実的に図っているといえることになります。

我々の検証に先駆けて、ESGは現在のハイパーコンバージドの市場を調査し、いくつかの結論に至っています。そのうちの一つが「コンピューティングおよびストレージの両方を活用するトランザクションヘビーなアプリケーションという観点からは、ハイパーコンバージドソリューションは予測性のある一貫したパフォーマンスを拡張時に提供することができない」というものでした。我々の検証をもとにすると、彼らは残念なことにその誤った概念を認めなくてはなりませんでした。つまり「・・・[Nutanixの]OLTPデータベース環境はデータベースインスタンス数が倍になっても予測性のあるパフォーマンスを提供できる、加えてクラスタ全体にIOPSが分散したとしても応答時間は一貫して低く、さらにデータがより大きくなったとしてもそれが実現できる」

個人的にこの結果を見直した際に、私は更に幾つか思うところがありました。自身のキャリアを最近はストレージのパフォーマンスやフラッシュ関連の現場に費やしているため、私はオールフラッシュのソリューションを導入することでデータセンタに一貫した、継続的なパフォーマンスをも足らせる可能性があるということは知っていました。しかし、このオールフラッシュを完全に利用するとなると、従来のメディアに加えてより多くのCPUサイクルが必要になります。CPUをより多く利用するSQL Serverのようなアプリケーションの要件を考えあわせるとこれはパフォーマンスについての麻薬のようなものになりかねません。最終的に我々は超低遅延をホスト内のストレージ(データローカリティ)で実現することができることを示し、さらにあらゆる他のオーバーヘッドを排除できることも示すことができました。ほぼリニアなIOPSと拡張しても低遅延を維持できることが合わさっていることがNutanixプラットフォームのパフォーマンスの秘伝のタレなのです。

SQLの検証とパフォーマンスの数字の詳細についてはESGのレポートを入手して下さい。そして、Nutanix Nextコミュニティでどう思ったのか教えてください、そして更に会話を続けましょう。

レポートはこちらからダウンロードできます。

議論しましょう : 我々のコミュニティのフォーラムで会話をづづけましょう。  

© 2017 Nutanix, Inc.  All rights reserved. Nutanix and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

Andyさん、やっぱり訳しにくい!(笑) 今回は前回のパート1に引き続いて、SQL Serverのパフォーマンスについて更に詳細が明かされます。ですが、記事を読んで分かる通り、問題はストレージではなくCPUです。Nutanixには強力なCPUを搭載することができますが、その強力なCPUを用いてさえ、オールフラッシュ構成のNutanixのストレージパフォーマンスを圧倒することは(OLTPでは)できません。

Andyさんが言うように、アプリケーションのことを考えるとHCIをストレージとして評価することがどれだけ愚かなことなのか、そしてその評価でものを買ってしまうと・・・ゾッとしますね。

また、NutanixのスケーラビリティについてもESGの当初の想定を覆すほどの結果だったということも重要です。Nutanixはローカリティがありますので仮想マシンから見たときに、そのI/O性能を決めるノードはわずか、2(RF2の場合、RF3なら3)ノードです。どんなにクラスタが大きくなってもこの鉄則は崩れることがありません。スケーラビリティというより、実際にはスケールアウトしても影響範囲が限定的なのでリニアに性能を伸ばしていくことができるのです。この考え方はAndyさんの古巣のPernixDataと同様ですね。

2017/06/07

NutanixがMicrosoft SQL Server環境の移行をシームレスにする

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のTechnical Marketing EngineerであるMike McGhee氏によるものです。原文を参照したい方はMaking Migration Seamless for Microsoft SQL Server Environmentsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

Fig226

展開と利用が簡単なエンタープライズクラウド環境で管理者がアプリケーションについての業務に集中することができます。今日もっとも広くインストールされ、そして仮想化されているミッションクリティカルアプリケーションはMicrosoft SQL Serverです。SQL Serverの仮想化はリソースのより効率的な利用、可用性の改善、ハードウェアプラットフォームを跨いでの柔軟な可搬性を含む多くのメリットを提供します。SQL Serverのようなミッションクリティカルアプリケーションが仮想化のメリットを確実、惑うことなく享受できるようにすることは、究極的にはなぜ特定のプライベートクラウドまたはパブリッククラウドのテクノロジーを選ぶのかというところに至ります。

SQL Serverをシームレスに移行させることができるということはパフォーマンスが向上し、管理が簡単になって、究極的にはビジネス収益を改善できる昨今のテクノロジーを活用しようとした場合にはとても重要です。しかし、移行をするとなると常に怖さがつきまといます。現状のニーズと将来の成長についてサイジングし、移行先環境へベストプラクティスを施したSQL Serverを展開し、限られたダウンタイムの中で移行を実施するということは多くの配慮が必要ですし、心配事もつきません。

NutanixのエンタープライズクラウドはMicrosoft SQL Serverにとって理想的なプラットフォームです。Nutanixへの移行を可能な限りシンプルで、そして簡単なものにしようという目的の元、NutanixはSQL Server Mobility Service(SSMS - SQL Server可搬サービス)を開発しました。SSMSは以下のような難題を含む移行タスクにおいて最初から最後までお手伝いをするツールです。

  • 現在のSQL Server環境の分析
  • SQL Serverワークロードのための移行先としてのNutanix環境のサイジング
  • Nutanixプラットフォーム、仮想化、そしてSQL Serverのベストプラクティスの定義
  • Nutanix環境へのカットオーバーを含むSQL Serverデータベースの移行の自動化

では、SSMSはどのように動作する?

まずSSMSはエージェントレスで動作します、つまり移行元や移行先の環境にソフトウェアをインストールする必要はありません。SSMS自身は仮想化アプライアンスで、OVAフォーマットで提供され、最小インストール構成のLinuxが動作しています。Linux内にはDockerベースのコンテナがインストールされており、そこでSSMSを動作させるNutanixイメージが起動します。OVAの展開に際してはIPアドレスが1つ必要で、標準ではDHCPで、または管理者が静的に割り振ることもできます。そのIPアドレス上でSSMSは標準のインターネットブラウザを利用してHTML5ベースのインターフェイス経由で操作を行います。インストールには数分ほどの時間がかかります。

SSMSへ接続すると4つのコアとなる操作が表示されます。スキャン、設計、展開、そして移行です。これらの操作はみなさんが定義する「プロジェクト」の下にグループされています。さぁ、これらのコンセプトの詳細を掘り下げていきましょう。

SSMS Projects: まずはじめに

プロジェクトはユーザーが定義する論理構造体でご自身の環境を構成するのに役立ちます。特定のSQLインスタンスを個別のプロジェクトに当てはめることもできますし、複数のSQLインスタンスで一つのプロジェクトを共有することもできます。皆さんの思うがままです。いつでもプロジェクトへ立ち戻る事ができますし、特定の操作を行うか、どうした操作が行われているのか確認することができます。

最初にSSMSにログインした際には新しいプロジェクトを作成するか、もしくは既存のプロジェクトのリストを検索するか訪ねてくるホームページがお出迎えします。

Fig227

プロジェクトを作成後はSQL Serverのスキャニングです。

SSMS Scans: 環境の自動探索

SSMSのスキャン操作はエージェントレスでのSQL Server環境の自動探索です。プロジェクト内でマルチスキャンを選択することができ、1つまたはいくつかのSQLインスタンスのスキャンを実行します。SSMSはこの操作をSQL Serverに対して直接実行しますので、ターゲットとなるSQLインスタンスに権限のあるアカウントが必要となります。接続が済むと、SSMSはトランザクションSQLのselect宣言の群とホストコマンドを幾つか実行します。最初のリリースのSSMSは大体40ほどのクエリを実行し、その中から以下の情報を取り出します:

  • OSとSQL Serverのヴァージョン
  • SQL Serverのインスタンス名と利用しているネットワークポート
  • Active Directoryの詳細
  • OSとSQL Serverに割り当てられたメモリ
  • ホストに割り当てられたプロセッサコアとSQLアフィニティ設定
  • 割り当てられたストレージと消費量
  • データベースの構成とレイアウト
  • バックアップ履歴
  • パフォーマンス統計情報:
    • 現在のメモリ消費量
    • CPU利用率の履歴
      • 注 : CPUカウンターは4時間の間隔で浮動平均されます
    • ストレージの帯域とIOPSの履歴
      • 注 : ストレージの統計情報はそのインスタンスのSQL Serverサービスが再起動されてからの平均の結果から取得されます

スキャンはインスタンスあたり大抵1分ほどですので、煩わしいものではありません。スキャン結果のサマリ概要とインスタンス内で見つけてきたデータベースについて表示するデータベースレベルでのサマリが得られます。

Fig228

SSMSによってスキャンの結果が表示され既存の環境についてより深く理解ができることでしょう。更には移行の計画のためのベースラインとなる要件も表示されます。ですが、SSMSは単に情報を取得してくるだけのためだけに設計されているのではありません。理想的なターゲット構成を自動化するためにも利用が可能です。これは次のステップ、設計のフェーズでお目見えします。

SSMS Design: ベストプラクティスの定義

設計操作は取得したスキャンデータとベストプラクティスルールエンジンを利用して自動的にターゲットの構成を行います。SSMSによって推奨された構成を以下で確認することができます、またはスキャンで取得した入力情報とシンプルなYAML TOSCA仕様に則ったデザインテンプレートフォーマットの両方を含む設計情報をダウンロードすることもできます。

Fig229

Fig230

Fig231

ルールエンジンは多くのNutanixの、そして仮想マシン、SQL Serverレベルでのベストプラクティスを含んでいます、以下はその一部です:

  • Nutanixストレージコンテナ構成とインライン圧縮
  • vmxnet3ネットワークアダプタと複数のPVSCSIアダプタなどの特定の仮想化ハードウェア
  • 一時DB(tempdb)やユーザーデータベース用の複数の仮想化ディスク、vCPUの数も考慮に入っています
  • アロケーションユニットサイズ64KBでSQLファイル用に仮想化ディスクをフォーマット
  • 既存のニーズと将来の成長を考慮した仮想化ディスクのサイズの割当
  • 以下のようなSQL設定
    • インファントファイルの初期化
    • メモリ上でのロックページ
    • エクステントサイズの混在の回避
    • ファイルの自動拡張
    • メモリでラージページ割当を利用、SQL Serverに割り当てられたメモリから

設計仕様はその後ターゲット構成の作成に利用されます。これはSSMSの次のパートである展開フェーズで行われます。

SSMS Deploy: 移行先を自動的に生成

SSMSはデータベースを移行元と移行先の間のSQL Serverインスタンス間でコピーすることで移行を実行します。移行計画を実行する前に、SSMSはまずベースOSとSQLインスタンスを展開し、利用できるようにします。最初のリリースではターゲットOSとSQLインスタンスは利用中のヴァージョンと同じでなくてはなりません。これまた最初のリリースではNutanix環境はESXiが動作しているものでなくてはなりません。

SSMSが展開手順を開始すするために以下の情報が必要です:

  • Prism管理のアドレスと認証情報
  • vCenter管理のアドレスと認証情報
  • 適切なヴァージョンのWindowsの仮想マシンテンプレート
  • WindowsをActive Directoryに追加できるドメイン認証
  • SQL Serverサービスのアカウント情報
  • 適切なヴァージョンのSQL Serverの.isoイメージ

これらを入力すると展開のサマリスクリーンが表示され、ここからは自動化された操作が行われます。

Fig232

展開の最中、SSMSはタスクを順次実行していきますが、最初はターゲット環境の作成が行われます。このタスクにはNutanixクラスタへのストレージコンテナの構成が含まれています。指定された仮想マシンテンプレートがクローンされますが、これにはNutanixのVAAIベースのファーストクローンを利用するため、非常に高速に行われます。クローンされた仮想マシンは指定されたActive Directoryへと追加され、SQL Serverがインストールされて、以前言及したベストプラクティスが適用されます。

Fig233

この処理が完了するとSQL Serverが動作している仮想マシンが移行先のNutanix上で動作している状態となります。さぁ、最後のフェーズに差し掛かりました。移行です。

SSMS Migrate: 自動化されたデータベース向けレプリケーション

SSMSの移行プロセスは移行元のSQLインスタンスと新しく展開された移行先の間の自動化されたデータベース、インスタンスのセキュリティ(ユーザーアカウント)、ジョブ(msdb経由)のレプリケーションを実現します。データベースはネイティブのSQL Serverバックアップと復元を使って移行されます。ログを利用した移行とよく似たとてもシンプルな概念での移行です。

処理は非常に簡単に実行できます、移行先のSQLインスタンスを選択して単に移行プランを作成すればこれまでに利用していたバックアップ操作が見つかります。もしネイティブSQLバックアップがアレばバックアップターゲットが簡単のために呼び出されます。もし移行先のシェアが利用できるのであれば既存のバックアップが利用されます。もし必要であればSSMSはSMBシェアのバックアップ先を利用して完全バックアップとログバックアップを実行するため、既存のバックアップは必要ありません。

Fig234準備完了したら、移行をスタートさせることができます。最初のステップではもしもターゲットにフルバックアップを戻す必要がある場合にはフルバックアップが実行されます。SSMSはSQLインスタンスに既存のスケジュールで取得されたすべてのログバックアップを問い合わせます。SSMSはインスタンスを継続的に監視し、これらのログバックアップを移行先に対して適用します。ログバックアップ監視プロセスが終了するとSSMSは2つのオプションを提供します。一つはテストカットオーバーで、もう一つは新しいインスタンスへの移行です。

テストカットオーバーではSSMSは既存のインスタンスをそのままにして、単にターゲットデータベースをリカバリモードから読み書き状態へと移行させます。この時点で移行プロセスが完了したと考えることができ、もともとの本稼働インスタンスとそのコピーのデータベースを新しいSQL Serverインスタンス内に持っていることになります。もし、後から本稼働インスタンスを移行しようと考える場合には単に新しい移行計画を作成し、同じバックアップと復元のプロセスを再度実行するだけです。テスト移行は移行プロセスが快適なものであると確認するために良いものですし、最終カットオーバー前にテスト環境としてステージングを行う他、簡単なPOC環境を作るのにも利用できます。

もし移行を実施するを選択した場合、移行元のSQLデータベースはシングルユーザーモードへと移行され、最終バックアップとトランザクションログの復元が実行されます。完全な移行が完了するためにはクライアントやアプリケーションを新しいSQLインスタンスへとリダイレクトしなくてはなりません。環境内でエイリアスを利用しているのであれば単にそのエイリアスに新しい移行先のインスタンスを追加すれば良いだけです。ですが、ファイナルテストカットオーバーや移行のステップが完了する前にSSMSは移行先のデータベースに幾つかのアクションを施します。

SQL Serverの観点から重要なベストプラクティスとして、単一データベース内のファイルグループでサポートできるデータファイル数があります。SSMSはMicrosoftの推奨事項を利用し、Write割当競合の回避のためのデータベースへのデータファイルの追加し、より多くのディスクへとストレージワークロードを拡張することができます。

Fig235

SSMSはまず最初にインスタンスにアサインされているCPU数と検出したストレージワークロードから追加データファイルをデータベースへと追加します。もし追加ファイルが追加されると追加ステップとして既存のデータファイルの縮退と既存のインデックスの再生性が行われます。このプロセスは既存のデータと新しいファイルのデータのバランスと偏りの除去です。これらの統計が更新された後、checkdbが実行されます。

これらの最終ステップはNutanix上の移行先のデータベースで可能な限りの最高のパフォーマンスを保証するためのもので、こうした退屈な作業をデータベース管理者が行う手間を削減することができます。

試してみる準備はできましたか?

構成管理はミッションクリティカルアプリケーションの一貫性のある環境とパフォーマンスを維持するためにより重要な役割を果たすようになってきています。構成管理の大原則を利用し、移行が確実にうまくいくことを保証しながら、ベストプラクティスを適応していくことは実に理にかなっています。もしここまで読み進めてきてSSMSを利用してみたいと思ったのであれば、ご提供いたします。SSMSはすべてのStarter、Pro、Ultimateいずれのエディションをご利用のNutanixのお客様へフリーで提供されます。もしもこのフレームワークが気に入ったのであればぜひ教えて下さい。我々は将来追加アプリケーションやユースケースをSQL Serverの枠を超えて提供していこうと考えています。Nutanix NEXT communityに参加し、SQL Server Mobility Serviceを動作させてどう思ったのか、教えて下さい!

Disclaimer: This blog may contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site. Please send us a note through the comments below if you have specific feedback on the external links in this blog.

© 2017 Nutanix, Inc. All rights reserved. Nutanix is a trademark of Nutanix, Inc., registered in the United States and other countries.  All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

Nutanixはあらゆるものをシンプルにしていこう、これだけを突き詰めているように見えます。Googleがあらゆるものを検索可能にし、Amazonがあらゆるものを1クリックで世界中どこにいても手に入るようにしてきたのと同じく、彼らの行動原理であるとおもいます。今回はSQL Serverの移行をシンプルにしてくれるツールがリリースされました。今までと動いているプロセスは同じなのですが極端に自動化して手間を省いてくれることはもちろん、その可読性をあげることでそれを実行する恐怖も取り除いてくれます。

もっとも仮想化されているデータベースであるSQL Serverの移行はそれだけで利用効果も高く、非常に面白いものですが、このSQL Server近年にもLinuxで動作するものがリリースされてきますし、中身はContainerで起動されるそうです。SQL ServerをWindowからLinux、仮想マシンからContainerへとこの分野のニーズは今後非常に大きなものになっていくのではないでしょうか。

ACSとSSPの統合でVMもコンテナも1クリックにしてきたNutanix社の次なる一手が垣間見えながら、さらにそれだけでも有用、SSMS今後注目の機能です!

2016/01/01

【連載】第6回 始めてみよう!CommVault Simpana データアーカイブ機能を活用してみませんか?

 

明けましておめでとうございます。本年も Simapan 関連の連載を続けて行きますので、どうぞよろしくお願いいたします。第5回では、Simpana の重複排除機能を利用した手法と、VMware 仮想マシンのリストア手法をご紹介しました。今回の第6回では、Simpana のデータアーカイブ機能をご紹介します。

 

今日、データの飛躍的な増大によって、企業は、いかにして日々増え続けるデータを管理するか様々な課題を抱えています。日々増加するデータに対して、従来の方法でバックアップを続けていけば、バックアップの取得に必要な時間と保管媒体の容量も同様に増え続けることは明らかです。

 

【データの増大に伴う管理者の課題】

  • 運用管理の複雑化
  • バックアップ時間の増加
  • データ復旧時間の増加
  • システム性能低下への懸念
  • コンプライアンス対策

 

増え続けるデータに対して、データ保護のために取得している定期的なフルバックアップは、更新頻度の低いデータを繰り返し保存することになり、非常に効率が悪いバックアップ運用を実施することになります。更新やアクセス頻度の低いデータに対して、アーカイブの仕組みを実装することによって、稼働系システム上のストレージからアーカイブ先となる 2次ストレージに対象データを移動し管理されますので、その結果、稼働系システム上のストレージ容量が削減されて、バックアップ時間の短縮が図れるようになります。

 

Simpanaのデータアーカイブ機能では、1つのタスク(ジョブ)の中で、バックアップおよびアーカイブの両方を定義することができます。保護対象のデータは、Simpanaの重複排除ディスクライブラリにバックアップされて、その後、アーカイブルールの条件に合致するデータが移動(削除)されます。アーカイブ後に生成される「スタブ」アイコンをダブルクリックすることにより、いつでもデータにアクセスすることができます。

 

【ストレージ有効活用のための Simpana データアーカイブ環境】

Archive002_3

 

【アーカイブデータにアクセスするための「スタブ」の表示】

Archive001_2

 

Simpana のアーカイブ対象には、ファイルシステム、メールボックス、及び VMware 仮想マシン等が含まれていますが、ここでは、NAS のデータアーカイブを説明させていただきます。NAS のアーカイブ方式としては、次の2種類が提供されています。

 

  • NAS ベンダー提供の API と連携した方式 (NetAppおよびEMC)
  • NAS ベンダー提供の API とは連携しない方式 (Isilon、HDS、等)

 

続きを読む »

2015/06/01

Microsoft Ignite 2015 に行ってみた①

みなさん、こんにちは!


ネットワールド Microsoft 担当SEの M です。


今回初めてブログ記事を投稿させていただきます。

これから少しずつではありますが、Microsoft の情報、ネットワールドとして取り組みをこのブログで発信していきますね!


今回最初の投稿ということで、

今年の5月4~8日に開催されたMicrosoft Ignite 2015

への参加のため、アメリカ シカゴに行ってきたお話をさせていただきます。

シカゴといえば、こちらが有名です!

 

シカゴピザ!!

20150509_051750_3

肉厚パリパリジューシーでおいしいですhappy01

シカゴ・カブス!!

20150504_023810_2

歴史を感じる ザ・ベースボールでしたconfident

と関係ない話はさておき、


Microsoft Igniteは今年初めてのシカゴ開催にもかかわらず、

全世界から約20000名、日本からは約40名の方々が

参加されました。


私自身も初めてのこのような大規模な海外イベント参加でしたが、

この人の熱気!!

20150504_230322_6

20150504_230910_2

初日から大盛り上がりでした!


本当にこれだけの方々、キーパーソンたちが一同に介している

というエネルギーに圧倒されました。

 

今回、Microsoft CEOのサティア・ナデラ からも述べられていましたが、


「クラウド・イノベーション」


今後はこれがMicrosoft の進む方向性といえそうです。

 

keynote セッションや詳しい内容については確認したい場合は、

こちらから確認することができます。

ぜひ見てみてくださいね。


次回からは内容についても詳しく載せていきますのでお楽しみに。

 

Microsoft 担当SE M