インフラ の記事一覧

「ハイブリッドクラウドへの道 ～The road to hybrid cloud.～ Vol.2」では、ハイブリッドクラウドのキモとなるAzure Active Directory（AAD）の基本操作を確認します。ドメインコントローラーをAzure Active Directory Domain Servicesに置き換えるにしろ、Office365などを利用するにしろ、AADは必ず必要となるシステムです。今回はAADの構築方法から、クライアントPCのAAD参加方法、AADのユーザーアカウントによるリモートデスクトップの接続方法までを紹介します。 Azure Active Directoryの作成 まずはディレクトリの構築から始めてみましょう。Azureポータルにログインします。ログインした時点で、実はすでにディレクトリは1つ作成されている状態となっています。TOPページから「Azure Active Directory」を選択します。 「既定のディレクトリ」という名前で、ログインしているユーザーのメールアドレスから生成された名前（*****.onmicrosoft.com）で既定のディレクトリが作成されています。Azureのサブスクリプションは必ず1つのディレクトリと紐づいている（別のディレクトリにサブスクリプションの紐づけを変更＝「ディレクトリの変更」することも可能です）ので、ポータルにログインした時点（Azureのアカウントを作成した時点）でサブスクリプションとディレクトリが割り当てられます。 ログイン直後は登録されているユーザーは自分1人だけの状態です。このまま既定のディレクトリを利用してもよいのですが、AADの理解を深めるために新しくディレクトリを作成してみましょう。 ポータルのTOPページから「リソースの作成」-「新規」-「ID」を選択します。 ディレクトリ作成に必要な情報を入力します。 たったこれだけの操作で新しいAADが無料で作成されました。 ユーザーの作成 ユーザーメニューから作成します。新しいディレクトリを作成したユーザー自身がすでに管理者として登録されていますが、「ソース」の項目に“外部のAzure Active Directory”と表示されています。元々のディレクトリと、新しく作成したディレクトリなど複数のディレクトリに跨ってユーザーは所属することができます。 この新しいディレクトリにユーザーを追加してみましょう。 左メニューから「ユーザー」-「新しいユーザー」を選択します。ユーザー情報を入力して作成します。 ユーザーを追加しました。ユーザー名はwin1@win2019ad.onmicrosoft.com（ユーザー名@ディレクトリ名）という表記になります。「ソース」の項目には“Azure Active Directory”と表示されています。このディレクトリが既定のユーザーとなります。 ユーザーにロール（権限）を設定します。このディレクトリの管理者として「グローバル管理者」のロールを割り当てます。 Azure Active Directoryに参加 では、新しく作成したアカウントでAADに参加してみましょう。今回はAzure上に仮想マシンとして作成したWindows10からの参加となります。ノートPCなどからでも、インターネットに接続できている環境であれば同様にAADに参加することが可能です。これは「Azure AD Join」と呼ばれる機能ですが、Windows10のみ利用できる機能となります（Windows Serverでは利用できません）。 【参考】Azure Active Directoryへの「参加」と「登録」AADに「参加」というと、Windows Server Active Directory（WSAD）＝オンプレミスのWindowsドメインに参加するのと同じようなものというイメージが強いとは思いますが、AADに参加することとは意味合いが異なります。前回も書きましたが、AADとWSADは別物です。AADに参加するということは、新しい認証サービスを利用するために参加する（登録する）ということになります。AADを利用することによって、様々なOSのデバイスからOffice365やAADに登録されたサービスのID管理を行うことが目的となります（Bring Your Own Device＝BYOD）。AADではユーザーが利用するデバイス単位にアクセス制限や管理することが可能です。 AADを利用する場合には、利用するデバイスに対して許可を与える必要があります。その方法が「参加」と「登録」になります。AADに「参加」できるデバイスはOSとしてWindows10を利用している場合だけです。Windows10からは「Azure AD Join」で参加が可能です。一方、AADに「登録」できるのはWindows OSだけでなく、Androidやアップル製のOSも含まれます。「参加」または「登録」されたデバイスだけがAADを利用して各種サービ AAD参加AAD登録対象デバイスOSWindows10Windows OSAndroidmacOSiOS Windows10からAADへの参加手順です。 まずはローカルアカウントでWindows10にログインします。スタートメニューから「設定」-「アカウント」を選択します。 左メニューから「職場または学校にアクセスする」を選択して「接続」クリックします。 「このデバイスをAzure Active Directoryに参加させる」を選択します。 先ほど作成したユーザー名を入力します。 ユーザー作成時のパスワードを入力します。 AADに初めてサインインする場合、パスワードの更新が必要となります。 「参加する」を選択します。 AADに参加できました。 参加後には「Azure ADに接続済み」との表示が確認できます。 ドメインとワークグループの設定では、変化はなくワークグループのままです。 Windows10の管理ツール「ローカルユーザーとグループ」から、Administratorsグループを確認してみると、”AzureAD\wini1”のユーザーがローカル管理者グループに登録されています。 Azureに戻ってAADのデバイスメニューを確認してみると、AADに参加したWindows10デバイスと所有者（ユーザー）が紐づいて確認できます。 AADのアカウントでリモートデスクトップ接続 AADに参加できたので、一度サインアウトして、AADのユーザーからリモートデスクトップ接続でWindows10にサインインをしてみましょう。 リモートデスクトップ接続のクライアントツールを利用します。AADのアカウントで接続する場合、いくつか特別な設定が必要となります。 まず、接続するためのユーザー名は“.\AzureAd\ユーザー名”という形式になるため、“.\AzureAd\win1@win2019ad.onmicrosoft.com”となります。 ユーザー名は接続設定ファイルに保存したほうが便利ですが、未入力で接続のたびに入力しても問題ありません。 一度この接続情報でRDPファイルとして保存します。 先ほどの設定で保存したRDPファイルをメモ帳で開きます。AADのアカウントでリモートデスクトップ接続を行う場合は、「CredSSPを用いた接続を行わない」という設定が必要となります。 “enablecredsspsupport:i:0”この一文を追加します。 ユーザー名まで含めると、enablecredsspsupport:i:0username:s:.\AzureAd\win1@win2019ad.onmicrosoft.comを追加して保存します。 RDPファイルをダブルクリックしてみましょう。ユーザー名のところに“AzureAD\”から始まるユーザー名が入力されています。パスワードを入力すればAADのアカウントでサインインし、通常のリモートデスクトップ接続が利用できます。 リモートデスクトップから確認してみると、ログインしているユーザーがAADのアカウントとなっています。 AADのアカウントでサインインしているので、AADでサービスを登録すれば、Windows10からは以後追加の認証無しにシングルサインオンで様々なサービスを利用することができるようになっています。 以上、Azure Active Directoryの基本操作の紹介となりました。少しずつですがハイブリッドクラウド実現に向けて近づいていきましょう。次回は、Azure Active Directory Domain Servicesを紹介します。

クラウドファーストをキーワードに、クラウドの利用がようやく当たり前の時代となりました。そんな中、すべてをクラウド化するにはどうしても無理な部分もあり、オンプレミスでのサーバー利用も依然として続いているのも事実です。クラウドとオンプレミスの使い分け、連携するための様々な技術や手法が出揃ってきています。今回よりスタートする新連載では、Windows ServerとAzureを中心にクラウドとオンプレミスの融合「ハイブリッドクラウド」を目指すべく、独断と偏見を交えて技術情報を紹介していきます。題して、「ハイブリッドクラウドへの道 ～The road to hybrid cloud.～」！ Azure Active Directory と Azure Active Directory Domain Servicesの概要 まず第1回目は「Azure版Active Directory サービスの使いどころ」ということで、オンプレミスのActive Directoryを管理している方にはちょっと誤解しやすいAzure Active DirectoryとAzure Active Directory Domain Servicesの概要を紹介します。 Active Directoryと名前の付くものが、Microsoftには数多く存在しています。まずはオンプレミスでこれまで利用されてきたお馴染みのActive Directoryです。他との比較をしやすくするため「Windows Server Active Directory」＝WSADとします。2つ目は、「Azure Active Directory」＝AADです。もう1つ紹介するのは「Azure Active Directory Domain Services」＝AADDSです。 他にもActive Directoryと名の付くサービス、機能がたくさんありますが、まずはこの3つの違いをきちんと理解しておく必要があります。サーバーを自らセットアップしてWSADを構築していたエンジニアからすると、「Azure Active Directory」とう名前から、Azure上でActive Directoryを構築してドメインに参加したユーザー管理とPCの管理ができるものという印象があるかと思います。 では、「Azure Active Directory Domain Services」って何なの？ という疑問も当然出てきます。 Active Directoryで検索したところ これらの違いをきちんと理解して使い分けることが、ハイブリッドクラウドへの最初の一歩となります。 細かい機能の説明は後ほどということで、まずはそれぞれの大まかな機能や役割を確認しておきます。 WSADAADAADDS用途オンプレミスでのアカウント管理。対象はWindows PCクラウド環境でのアカウント管理。対象はOSを問わず各種デバイスクラウド版WSAD。アカウント管理はAADに依存使用例社内アカウント・PC管理。ファイルサーバーのアクセス権。グループポリシーOffice365へログイン。Webアプリケーションの認証。タブレットからシングルサインオン。多要素認証Azure仮想マシンのドメイン参加。社内ドメインをクラウドに移行・同期制限事項インターネットに公開はNG。VPNや専用回線を推奨WSADとADDは別の機能。Windows Serverは参加できないDomain Admins・Enterprise Adminsがない。Domain Policyの変更ができない。オンプレと同期できるが、一部制限あり※WSAD：Windows Server Active Directory　AAD　　：Azure Active Directory　AADDS：Azure Active Directory Domain Services Windows Server Active Directory Azure Active Directory Azure Active Directory Domain Services それぞれの概要を理解したところで、長年オンプレミスのWindows Serverに携わった経験から各Active Directoryサービスの使いどころを以下のように考えました。 WSADとAADは別物 まずAADは、これまで自分たちが経験を積んできたWSAD、いわゆるWindowsドメインとはまったくの別物ということです。クラウドサービス全盛の中、サービスを利用する端末は必ずしもWindows PCだけではなく、スマートフォン、タブレット、IoT端末など様々なOSやデバイスが考えられます。これらのアカウント、端末管理をするための新しいID管理の仕組みが必要となります。クラウドサービスをシングルサインオンで利用するためのアカウント管理システムがAADということです。WSADをまったく意識せず、クラウドサービスだけを利用するような環境であればAADの選択が最適です。 AADDSはドメインコントローラーの代わりとなる Azure上に作成した仮想マシンをドメインに参加させてオンプレミス同様に管理する場合、仮想マシン自体にドメインコントローラーの機能をインストールしてドメインを構築することが可能です。このドメインコントローラーの仮想マシンの代わりとなるものが、AADDSです。ドメインコントローラーのPaaS（クラウドサービス）と言い換えることができます。ドメインコントローラー構築、運用の面倒な部分を、サービスを利用することで簡略化し、仮想マシンのリソースを削減できます。ただし、オンプレミスと同様のActive Directoryの機能が100％利用できるわけではなく、Domain Admins・Enterprise Adminsがないことや、Domain Policyの変更、ドメイン同士の信頼関係の設定、スキーマ拡張、フォレスト、Active Directoryの機能レベルの変更など、利用できない機能があります。 WSAD とAADDSの同期、移行には制限がある ハイブリッドクラウドを目指す場合、既存のオンプレミスのWSADとAADDSの同期や移行が必要になります。この場合、Azure AD Connect（オンプレミスのアカウント情報とAADのアカウント情報を同期するツール）を利用して同期することとなるのですが、同期できるオブジェクトがユーザーデータのみという制限があり、アカウント、グループ、パスワード、SIDだけに限定されます。グループポリシー、コンピューターオブジェクトは同期対象外となります。コンピューターオブジェクトにアクセス制限などを設定している場合は注意が必要です。また、デスクトップのテンプレートイメージや、セキュリティーポリシーなどグループポリシーで制限をしている場合には、オンプレかクラウドかでPCの仕様に差異が出る可能性があり注意が必要です。 AADDSはActive Directoryの新規作成がおすすめ AADDSを利用する場合は、新規でActive Directoryを構築して運用管理することが一番シンプルで使いやすそうです。オンプレミスにはドメインコントローラーは作らず、最初からAADDSを利用します。アカウントの同期やリソースの移行といった面倒な作業が必要なく、シンプルで使いやすい構成と考えられます。 ハイブリッドクラウドでActive Directoryを移行する場合　Azure仮想マシンあり ハイブリッドクラウドを実現するために一番現実的で問題が少なそうな構成は、Azure上で仮想マシンを作成し、VPN接続でドメインコントローラーを複製する方法です。この方法は、オフィスと遠隔地を結ぶActive Directoryの構築方法と同じ考え方なので、これまで経験してきた手法が利用できます。Azure上に追加で仮想マシンを作成した場合は、すぐ側にドメインコントローラーがいるので、そのままドメイン参加することが可能です。最終的にはオンプレミスのドメインコントローラーをすべてなくして、Azure上のドメインコントローラーのみといった構成も可能です。Azure上にオンプレミスのリソースを最適配置して、クラウドの利点である運用コストの削減やデータ保護に役立てることが可能となります。Office365などクラウドサービスを利用する場合は、Azure AD Connectを利用してAADとアカウント同期を行い、シングルサインオンを可能とします。 ドメインコントローラーとして仮想マシンを作成 ハイブリッドクラウドでActive Directoryを移行する場合　Azure仮想マシンなし Active Directoryはそのままオンプレミスのものを利用して、Office365などクラウドサービスを利用する場合は、Azure AD Connectを利用して、オンプレミスのドメインコントローラーとAADの間でアカウント情報の同期を取ることで、クラウドサービスとオンプレミスのリソースを1つの同じアカウントで利用することが可能となります。 オンプレミスのドメインコントローラーを利用 ドメインコントローラーを作成しない場合 ドメインコントローラーの役割を、すべてAADDSを利用することで置き換えます。オンプレミスでもAzure上の仮想マシンでもActive Directoryに参加することが可能となります。AADDSはAADと紐づいているので、Office365などクラウドサービスにシングルサインオンが可能となっています。ただし、AADDSはいくつか制限事項があるので、オンプレミスからの移行よりは、新規でAzure上にActive Directoryを構築する場合に適しているようです。 ドメインコントローラーをAADDSに置き換え 以上、「ハイブリッドクラウドへの道　～The road to hybrid cloud.～」連載のはじめは、「Azure版Active Directory サービスの使いどころ」ということで、サービスの概要とそれぞれの使いどころを紹介しました。 次回以降、各サービスの設定方法など詳細情報を紹介していく予定です。

「お名前.com デスクトップクラウド」では、リモートデスクトップという技術を利用してサーバーに接続します。今回はリモートデスクトップを利用するための設定内容を詳しく紹介します。 まずはサーバーに接続！ すでにサーバーが利用可能となっているので、まずは接続してみましょう！ 1番簡単な方法は、前回紹介したコントロールパネルの「リモートデスクトップ」メニューから「RDPファイルのダウンロード」を実行することです。 RDPファイルのダウンロード 「RDPファイルのダウンロード」ボタンをクリックすると、RDPファイルがダウンロードされますので、そのままダブルクリックするなどして実行します。すでに「サーバーの初期設定」で設定したユーザー名が入力されているので、同様に設定したパスワードを入力します。 RDPファイルの実行 画面いっぱいに接続先サーバーのデスクトップが表示されます。画面上部にバーが表示されていれば接続先のデスクトップが表示されていることになります。「for MT4」プランであれば、デスクトップ上に「Desktop Cloud MT4 Installer」というアイコンも表示されています。 「お名前.com デスクトップクラウド」はWindowsからだけでなく、Mac、AndroidやiPhoneなどのスマートフォン、タブレットからも接続することが可能です。 RDPファイルをダウンロードする接続方法は、WindowsやMacなどから接続する場合に利用可能です。スマートフォンやタブレットから接続する場合、いくつかリモートデスクトップ接続用のアプリが公開されていますが、それぞれのアプリに接続情報を入力して設定する必要があります。 リモートデスクトップ接続情報 コントロールパネルの「リモートデスクトップ」メニューには「リモートデスクトップ接続情報」が記載されています。これらの情報は手動で「お名前.com デスクトップクラウド」にリモートデスクトップ接続するために必要な情報となります。具体的に、どの部分に設定するべき情報なのかを詳しく見てみましょう。 リモートデスクトップ接続情報 先ほどダウンロードしたRDPファイルを右クリックして「編集」を選択します。 「リモートデスクトップ接続」のアプリケーションが起動します。すでにRDPファイルの内容に従って、いくつかの項目が設定されています。「資格情報を保存できるようにする」のチェックを入れておくと、一度ログインした情報を保存して、以後同じコンピューターから接続する場合は、パスワードの入力無しに接続できるようになります。 リモートデスクトップ接続アプリケーション コントロールパネルの「リモートデスクトップ接続情報」と見比べてみましょう。 設定項目の確認 「コンピューター」と「ユーザー名」に関しては、「接続先コンピューター名」と「ユーザー名」の情報が該当します。 詳細設定タブには「任意の場所から接続する」という項目があり、“リモートデスクトップゲートウェイ(RDゲートウェイ)”を利用するための設定を行うことができます。「詳細」ボタンをクリックすると、「サーバー名」には「RDゲートウェイサーバー名」の情報が該当しています。コントロールパネルにある、RDゲートウェイサーバー名の下の「ユーザー名」は、スマートフォンやタブレットから接続する場合に、アプリによっては必要となる情報です。 画面 ・画面設定ダウンロードしたRDPファイルでは、接続元の画面いっぱいにサーバーのデスクトップが表示されますが、設定を変えることで、画面より小さいサイズで表示することが可能です。 「画面」タブの「画面の設定」のスライダーを変更することで任意のサイズで表示されます。一番右の大にすると全画面表示となります。 「リモートセッションですべてのモニターを使用する」にチェックを入れると、接続元がマルチモニター環境の場合、複数のディスプレーにサーバー上のデスクトップを表示することが可能となります。 画面の設定 ・画面設定ダウンロードしたRDPファイルでは、接続元の画面いっぱいにサーバーのデスクトップが表示されますが、設定を変えることで、画面より小さいサイズで表示することが可能です。 「画面」タブの「画面の設定」のスライダーを変更することで任意のサイズで表示されます。一番右の大にすると全画面表示となります。 「リモートセッションですべてのモニターを使用する」にチェックを入れると、接続元がマルチモニター環境の場合、複数のディスプレーにサーバー上のデスクトップを表示することが可能となります。 画面サイズを小さくして接続 ・画面の色画面の色は、写真や動画などをサーバー側で表示する場合、色数が多ければより自然に近い色合いとなりますが、接続回線が遅い場合などは負荷が高く使用感が悪くなるため、色数を落とすことをお勧めします。 ・全画面表示バーこのチェックを外すと、全画面表示の際に画面上部のバーを非表示にすることができます。通常のウィンドウ状態に戻すときには、Ctrl」＋「Alt」＋「Break」を押して全画面表示を解除できます。 ローカルリソース ローカルリソースの設定 ・リモートオーディオリモートオーディオの設定では、サーバー側で再生された音声を接続元のコンピューターで再生したり、接続元のコンピューターのマイクを使ってサーバー側で録音するといった設定を行うことができます。 リモートオーディオの設定 ・キーボードWindowsキーが有効になる場合を設定します。Windowsキーは「Windowsキー」 + 「E」でエクスプローラーを起動するなど他のキーと組み合わせて様々なショートカットとして利用できます。 ・ローカルデバイスとリソース「プリンター」のチェックを入れると、サーバー側の印刷出力先に、接続元のプリンターを指定することができます。 「クリップボード」のチェックを入れると、サーバー側と接続元でクリップボードを介してテキストやファイルのやり取りが可能となります。ファイルのコピー中に同様にクリップボード経由で他の操作を行うとエラーとなってしまいますので注意が必要です。また、クリップボード経由でやりとり可能なファイルサイズは4GBまでとなります。4GB以上のファイルの送受信を行う場合は、以下のドライブのチェックを入れて、エクスプローラーで表示された接続元のドライブを利用してファイルのやりとりを行う必要があります。 ただし、リモートデスクトップ経由でのファイルの送受信ではいずれの方法でも速度が極端に遅いため、サイズの小さいファイルや、テキストなどの文字列にとどめておく方がよいでしょう。サイズの大きなファイルの送受信は、一度OneDriveなどクラウドのストレージサービスを経由するなどの方法をお勧めします。 ローカルデバイスとリソースの設定 接続元のドライブを参照 リモートデスクトップのファイルコピー エクスペリエンス エクスペリエンスの設定 エクスペリエンスでは、リモートデスクトップ接続時の回線速度によって、表示すべきデスクトップの機能を選択することができます。「接続品質の自動検出」を選択しておくと回線速度に適した設定を自動的に選択してくれます。 「ビットマップのキャッシュを保持」にチェックを入れておくと、リモートデスクトップ接続のパフォーマンスがアップするので、チェックをそのまま入れておくことをお勧めします。 「接続が損なわれた場合は再接続する」のチェックを入れると、何らかの理由でリモートデスクトップ接続が意図せず途切れた場合、自動的に再接続を行います。 詳細設定 詳細設定 ・サーバー認証サーバー認証が失敗した場合の警告表示の方法を設定します。 ・任意の場所から接続するリモートデスクトップゲートウェイの設定を行います。設定情報は、先ほど紹介したコントロールパネルの「リモートデスクトップ接続情報」の内容となります。 以上が、「お名前.com デスクトップクラウド」でリモートデスクトップを利用するための設定方法となります。様々な利用環境に最適な細かい設定が可能となっており、サーバーと接続元で簡単にファイルのやり取りもできるようになっています。また、「お名前.com デスクトップクラウド」では、RDゲートウェイを採用してセキュリティーの向上が図られていますので、安心して利用することができるようになっています。 生まれ変わったお名前.com デスクトップクラウド、ぜひその速さを体感してみてください。

前回までに、「お名前.com デスクトップクラウド」の申し込みが完了して、サーバーが使えるようになりました。今回は、サーバーを管理するためのコントロールパネルの使い方を紹介します。 コントロールパネルにログイン 「お名前.com デスクトップクラウド」のTOPページを表示してログインボタンをクリックします。 デスクトップクラウドTOPページ まずはサーバーを管理するためにコントロールパネルにログインします。 コントロールパネルにログイン デスクトップクラウドの申し込み時に発行された「お名前ID」でログインします。 お名前IDでログイン デスクトップクラウドのTOPページ以外にも、「お名前.com Navi」のサーバー一覧からログインボタンをクリックしてもログインが可能です。 お名前.com Naviからコントロールパネルにログイン 初期設定 コントロールパネルのTOPページでは、申し込みが完了したサーバー一覧を確認することができます。複数台申し込みをした場合はこの一覧にサーバーが追加されていきます。サーバーを利用するためにはまず初期設定を行う必要があります。 「初期設定へ進む」をクリックします。 初期設定へ進む 初期設定画面では、サーバーにログインするためのユーザー名とパスワードを設定します。ユーザー名とパスワードはサーバーごとに設定する必要があるので、複数台申し込みを行っている場合はその都度設定することになります。また、ユーザー名とパスワードはコントロールパネルを使って後から変更することが可能です。入力を行ったら「実行」ボタンをクリックします。 ユーザー名、パスワードの設定 サーバーのステータスが“稼働中”となっていれば、初期設定が完了していますので、利用可能状態となります。 利用可能となったデスクトップクラウド リモートデスクトップ 1つずつ、画面左のメニュー内容を確認していきましょう。 まずは「リモートデスクトップ」です。こちらはサーバーに接続するための情報がまとめられています。「お名前.com デスクトップクラウド」では、Microsoftが提供している、「リモートデスクトップ」という仕組みを利用して、サーバーに接続します。 「RDPファイルのダウンロード」では、サーバーに接続するための情報があらかじめ設定されている、リモートデスクトップ接続設定ファイルをダウンロードすることができます。ダウンロードしたRDPファイルは、Windowsからであれば、面倒な設定内容を入力することなく、そのまま起動してパスワードだけ入力すればそのままサーバー接続が可能となっています。MacでRDPファイルを利用する場合は、あらかじめMicrosoftが提供する「Microsoft Remote Desktop」をインストールすることで、そのまま利用可能となっています。 その他、Androidのスマホやタブレットから接続する場合は、「リモートデスクトップ接続情報」に書かれている内容を元に入力設定を行います。 「リモートデスクトップご利用ガイド」では画像付きで詳しく接続方法が紹介されています。 リモートデスクトップ メニュー コンピューターの操作 「コンピューターの操作」では、接続先のサーバーの状態やスペック情報が確認できます。 「現在のステータス」では、サーバーの稼働状況を確認できます。“稼働中”であれば、サーバーに接続可能な状態となっています。また画面をキャプチャーしたイメージ画像でも稼働状況が確認できます。もし、稼働中にも関わらずリモートデスクトップで接続できなくなったり、サーバーが固まってしまった場合などは、「強制再起動する」をクリックすると、一度サーバーをリセット（データーは残ったまま）することで回復することがあります。 「コンピューターの情報」では、契約しているサーバーのスペックが確認できます。メモリを増やしたいなどの場合は、「お名前.com Navi」に一度ログインして、プラン変更することでスペックアップすることが可能です。 コンピューターの操作 メニュー ユーザー名/パスワード変更 「ユーザー名/パスワード変更」では、リモートデスクトップでサーバーに接続する際の、ユーザー名とパスワードを変更することができます。 また、コントロールパネルにログインするIDは「お名前.com Navi」のお名前IDとパスワードとは別となっているので、もしリモートデスクトップのパスワードを忘れてしまった場合でも、こちらから再設定が可能です。 ユーザー名/パスワード変更　メニュー コンピューターの初期化 こちらのメニューでは、サーバーを最初の状態に戻すことが可能です。「コンピューターの操作」から「強制再起動」を実施してもリモートデスクトップでログインできない場合や、サーバー内での設定や変更をすべて元に戻す場合などに利用します。「コンピューターの初期化」を行うと、サーバー上に保存されたデーターやすべての設定内容が失われることになるので、利用時には注意が必要です。 「コンピューターの初期化」後は、これまで利用していたユーザー名とパスワードで引き続き利用が可能です。 コンピューターの初期化　メニュー 以上が、「お名前.com デスクトップクラウド」でサーバーを管理するための「コントロールパネル」の使い方となります。 次回は、実際にサーバーにリモートデスクトップで接続して、サーバーの利用方法や、リモートデスクトップの接続情報の詳細な内容を紹介する予定です。 生まれ変わったお名前.com デスクトップクラウド、ぜひその速さを体感してみてください。

生まれ変わった「お名前.com デスクトップクラウド」～申し込み編～ 前回、新しくなった「お名前.com デスクトップクラウド」の概要を紹介しました。今回は、実際にデスクトップクラウドを使い始めるまでの申し込み手順について、1つずつ紹介します。 デスクトップクラウドの利用申込み まずは、「お名前.com デスクトップクラウド」のTOPページ（https://www.onamae-desktop.com/）を表示します。 デスクトップクラウドでは2種類のサービスが用意されています。FX用途向けに、あらかじめMT4がインストールされている「for MT4」と、通常のWindowsデスクトップが利用できる「for Biz」です。最初の画面で、右上の「お申込み」ボタンをクリックすると「for MT4」の申し込み画面となります。「for Biz」を申し込みたい場合は、画面上の、”for Biz”をクリックしてから、「お申込み」ボタンをクリックします。 デスクトップクラウドTOPページ for Bizの申し込み画面 申し込みをしたいプランを選択します。プランを選択すると支払い期間が表示されますので、こちらも選択します。まとめ払い期間が長いほど1ヶ月あたりの利用料が安くなっています。 プラン料金 プラン詳細 ここで、少しプランの詳細を説明しておきましょう。 プランは2種類、「for MT4」「for Biz」ともに、メモリ、CPU、ディスク容量ごとに価格が分かれています。また、共通仕様として、OSはWindows Server 2019、オールSSD採用、Google Chromeのプレインストールとなっています。「for MT4」はこれに加えて、「Desktop Cloud MT4 Installer」が用意されており、証券会社数社のMT4があらかじめ用意されていますので、ダウンロードの手間なくすぐにMT4が利用可能です。既存の証券会社以外のMT4も、ユーザー自身でダウンロードして利用することが可能です。 for MT4のデスクトップ for Bizのデスクトップ プラン選択後 プランと利用期間を選択して、画面右上の「次へ」ボタンをクリックします。初めてデスクトップクラウドを利用する場合は、メールアドレスとパスワード、すでにデスクトップクラウドを利用したことがある場合は、“お名前IDをお持ちの方”を選択して、ボタンをクリックします。 申込みの実行 すでに、お名前IDのユーザー登録が完了している場合は、支払い方法選択の画面に進みます。 初めてお名前.comのサービスを利用する場合は、お名前IDが発行されます。こちらは、以後ログインする場合に必要となります。ユーザー登録をするために必要な項目を入力します。ここに入力した電話番号で、申し込み完了後に電話認証による本人確認を行うことになります。 「次へ進む」をクリックします。 必要項目の入力 支払い方法を選択します。カード以外の支払い方法を希望の場合は「その他の支払い方法はこちら」をクリックします。カード以外では、コンビニ払い、銀行振り込み、請求書支払いが選択可能です。支払い方法を入力したら「申込む」ボタンをクリックして申し込みを確定します。 支払い方法の選択 申し込み完了 申し込みが完了すると、登録したメールアドレス宛に、“[お名前.com] デスクトップクラウド　お申込み確認”という件名でメールが届きますので、申し込み内容を確認します。利用開始までの流れは以下となります。 1.電話認証の手続きメール内に、電話認証による本人確認のための「認証用URL」が記載されていますので、クリックして電話認証を完了します。 2.請求明細の確認と支払い選択した支払い方法により異なります。メールに記載された手続方法に従って支払いを確定します。カード払いの場合はカード情報の確認が完了次第利用可能となりますので、より早く利用可能となります。 3.サーバー設定の開始支払いが確定すると、“[お名前.com] デスクトップクラウド サービス設定完了”という件名でメールが届きますので、記載内容に従いサーバーの初期設定を行います。 4.サービス利用開始サーバー設定完了次第、デスクトップクラウドが利用可能となります。 申し込み完了後のメール お名前.com Navi と コントロールパネル お名前.com デスクトップクラウドでは、申し込み情報を確認するための「お名前.com Navi」とサーバーを操作するための「コントロールパネル」が利用できます。「お名前.com デスクトップクラウド」のTOPページの「ログイン」ボタンをクリックすると、ログイン画面に移動します。 TOPページからログイン ログイン画面では、「お名前.com Navi」と「コントロールパネル」のどちらにログインするのかを選択します。コントロールパネルはサーバーが利用できるようになってからログイン可能となるので、今回は「お名前.com Navi」にログインしてみましょう。 ログイン画面 「お名前.com Navi」のTOPページでは様々なサービスの契約情報を確認できるようになっています。デスクトップクラウドの契約情報は右上の「デスクトップクラウド」をクリックして確認できます。 お名前.com Navi 先ほど申し込みをしたデスクトップクラウドのサーバーが確認できます。この段階では支払い情報の確認待ちなので、まだサーバーを利用することができません。サービス設定完了メールが届くか、「お名前.com Navi」の画面で、サーバーへの「ログイン」ボタンが表示されるまでしばらく待ちましょう。 申し込みをしたプランをクリックすると、サービスの詳細画面が表示されます。 申し込み状況の確認 サービス詳細画面では、よりスペックの高いプランへの変更や、解約、まとめ払いへの変更などを行うことができます。 サービス詳細画面 設定完了メールが届き、サーバー一覧を確認すると、コントロールパネルへの「ログイン」ボタンが表示されました。これでサーバーを利用することができるようになりました。 サービス設定完了メール このままログインボタンをクリックすることでコントロールパネルに進むことができます。また、デスクトップクラウドのTOPページのログインからもコントロールパネルに進めるようになっています。 利用可能状態になったサーバー サーバーが稼働中になると、サーバー一覧のプラン名をクリックすると確認できるサービス詳細の項目が増えています。メモリを増やしたいなどのプラン変更や、コントロールパネル情報、リモートデスクトップの接続情報などが確認できるようになっています。 サービス詳細 以上が、「お名前.com デスクトップクラウド」でサービスを使い始めるまでの申し込み手順となります。 次回は、実際にサーバーが利用できるようになったので、サーバーを管理するための「コントロールパネル」について詳しく紹介していく予定です。 生まれ変わったお名前.com デスクトップクラウド、ぜひその速さを体感してみてください。

2010年からサービスを開始し、これまで延べ13万台以上の仮想デスクトップを提供してきた「お名前.com デスクトップクラウド」が2019年1月23日にフルリニューアルして生まれ変わりました。セキュリティーが向上した最新のOS「Windows Server 2019」を採用し、すべてのプランでパフォーマンスを圧倒的にアップするSSDを採用することで、ストレスを感じることのない仮想デスクトップを提供しています。今回は概要編として、プランや料金について紹介します。■お名前.com デスクトップクラウドhttps://www.onamae-desktop.com/ [新]デスクトップクラウド サービス開始時点では、大きく分けて2つのプランが用意されています。仮想デストップ上でFXの自動売買アプリケーション「Meta Trader 4（MT4）」を利用するユーザー向けに、あらかじめMT4が同梱されている「for MT4」と、一般的な仮想デストップとして利用できる「for Biz」です。 それぞれのプランにはスペックごとにさらに細かくプランが分かれていますが、「for MT4」のライトプラン以外は、スペック、価格ともにどちらも同じとなっています。 FX専用 「for MT4」プラン 専用仮想デスクトップ「for Biz」プラン メモ：仮想デスクトップとは？ インターネット上に用意されたコンピューター（仮想マシン）に、ユーザーは手元のコンピューターから接続して、2台目以降の別のコンピューターとして利用できるサービス。接続先のコンピューターにはWindowsがインストールされており、デスクトップがいつも通りの操作で利用できる。接続元となるコンピューターは、Windowsの他に、Macやスマホ、タブレットからでもWindowsのデスクトップを利用可能。 手元のコンピューターからインターネット上の別のコンピューターに接続して利用できる どんなシーンでも利用できる仮想デスクトップ 料金プラン 「for MT4」と「for Biz」の料金プランを見てみましょう。「for MT4」「for Biz」どちらも初期費用は無料で、まとめ払いをするほど1ヶ月あたりの利用料金が安くなっています。 まずは、「for MT4」です。 「for MT4」の料金プラン 「for Biz」との違いは、あらかじめいくつかの証券会社が提供しているMT4が同梱されていて、ダウンロードすることなくすぐに利用できる点です。もちろん、これ以外の証券会社のMT4も自身でダウンロードしてインストールすれば利用可能です。 すぐにMT4を始められる「for MT4」 次に「for Biz」です。 「for Biz」の料金プラン MT4は特に必要無いという、ビジネス用途、個人用途の仮想デスクトップ利用の場合はこちらのプランが最適です。MT4があらかじめ同梱されていない点とライトプランが無いこと以外は、価格、スペックともに「for MT4」と同じラインナップとなっています。すべてのプランでSSDが採用されているので、デスクトップの操作感はこれまでのものとは段違いに快適です。 価格とスペックのバランスが一番良いのは2GBプランとなります。Windowsデスクトップの操作にはある程度のメモリが必要です。SSDの採用と合わせて2GBのメモリが搭載されていれば、ほとんどの場面でストレスを感じることなく仮想デスクトップを利用することができます。 デスクトップクラウドを利用すれば、パソコンを買い替えることなく快適にサクサク動く最新のWindowsデスクトップを手に入れることができます。 何が変わった？ [新]デスクトップクラウド これまでのデスクトップクラウドと何が変わったのか見てみましょう。 [旧][新]サーバーOSWindows Server 2012Windows Server 2019デスクトップOSWindows Server 2012R2 / 2008R2Windows Server 2019プラン-1.5GB、ライトプランを追加コア数表記ディスクHDDSSDMT4標準MT4を同梱標準・主要4社のMT4が同梱その他追加インストール可能（ライトプランを除く）リモートデスクトップ接続方法IPポート設定RDゲートウェイ方式ユーザー名の変更不可可コントロールパネルからのパスワードの変更コントロールパネルのパスワードのみコントロールパネル、リモートデスクトップのパスワード変更可プレインストールアプリ標準MT4（for FX）Google ChromeDesktop Cloud MT4 Installer（for MT4/ライトプランを除く）回線速度100Mbps100Mbps パフォーマンス以外では、最新のOS「Windows Server 2019」をサーバーとデスクトップ両方のOSに採用することで、最先端のセキュリティーで守られた安心して利用することのできる仮想デスクトップが提供されているのが注目すべき点となります。 デモンストレーション ではここで、MT4ユーザーのために実際に操作感がどれだけ変わったのか動画で紹介してみましょう。どちらも1GBプラン（1GBのメモリ、1コアのCPU）でMT4の起動時間を計測しています。 [旧]デスクトップクラウドでは、MT4の起動まで11秒要していたものが、SSD採用の[新]デスクトップクラウドでは5秒と半分以下になっています。数字で見ると半分ほどですが、実際に操作しているときの体感としては、イライラする時間もないほど数倍速くなったと感じることができます。（MT4は32ビットアプリケーションであり、64ビットアプリケーションのMT5の場合はさらに起動時間が速くなります） MT4に限らず、[新]デスクトップクラウドでは、デスクトップ上で動くすべてのアプリケーションでその速さを体感することができます。 さらに、動画をもう1つ紹介します。こちらは2GBプランでYouTube動画を視聴している場面です。このような動画であっても、安定したインターネット回線と併せて音声や映像が途切れることなく視聴することが可能です。（2GBプラン以上がおすすめです） 以上、生まれ変わったデスクトップクラウドの概要を紹介しました。 次回からは詳細な操作方法など交えて、デスクトップクラウドを快適に使いこなすためのテクニックを紹介していく予定です。 生まれ変わったお名前.com デスクトップクラウド、ぜひその速さを体感してみてください。

Windows Serverでは以前より、ソフトウェアRAIDと呼ばれるWindows ServerのOS自体の機能で、RAIDボリュームを構築することが可能となっています。RAID（Redundant Arrays of Inexpensive Disks）は複数のディスクを組み合わせて構築するディスクシステムで、複数のディスクを1つの大きなボリュームとして利用でき、冗長性の保持、パフォーマンスのアップを期待することができます。今回はWindows Server 2019のRAID機能としてこれまで提供されてきたものに、さらに記憶域プールの機能を組み合わせて、冗長性とパフォーマンスがより優れたRAIDディスクシステムを構築してみたいと思います。 ソフトウェアRAID 0・1・5 Windows Serverの「ディスクの管理」から構築できるRAIDボリュームを確認してみると、ボリュームの種類として、スパンボリューム、ストライプボリューム、ミラーボリューム、RAID5ボリュームの4種類が作成可能となっています。このうち、ストライプボリューム（RAID0）、ミラーボリューム（RAID1）、RAID5ボリューム（RAID5）がいわゆるRAID構成のボリュームということになります。スパンボリュームもRAIDと呼べそうですが、複数のディスクに分散してデータを書き込むRAIDとは別物として扱われているようです。 「ディスクの管理」で作成可能なRAIDボリューム 今回は各RAIDの特徴や構築方法などは割愛させていただきますが、それぞれのRAIDが単独のディスクに対してどれだけパフォーマンスと冗長性がアップするかを確認しておきます。（検証用として用意したものは、SATAのいわゆるひと昔前の遅いディスクです。） まずは、物理ディスク1台単体のベンチマークです。1台のディスク容量は465GBです。 ディスク1台のベンチマーク 次にRAID0＝ストライプをディスク3台で構築しています。容量は465×3=1395GBです。 ディスク3台RAID0のベンチマーク すでにRAIDのパフォーマンスについては様々なところで紹介されていますが、教科書通りRAID0のストライプ構成では、ディスクのRead・Writeのパフォーマンスがディスクの台数分だけ向上しています。組み合わせたディスクサイズ分、ボリューム容量を確保可能ですが、ディスクが1台でも故障してしまうとデータを失ってしまうというリスクを伴うのがRAID0となっています。 次にRAID1＝ミラーをディスク2台で構築しています。ディスク容量は1台分と同等の465GBです。 ディスク2台RAID1のベンチマーク ディスク2台から同時に読み取りが行われるので、Readのパフォーマンスが向上しています。Writeは1台の時とほぼ同じです。1つのデータを2台のディスクに同様に書き込んでいるため、ディスクが1つ故障したとしてもデータは保持されるので安全性が高いです。ミラーはディスク1台に対して1組となるため、ボリュームサイズはディスク1台のサイズが最大となります。 最後に、RAID5＝パリティーをディスク3台で構築しています。容量はパリティー分差し引かれて2台分の930GBです。 ディスク3台RAID5のベンチマーク パフォーマンスの良いRAID0のストライプに冗長性を持たせたのがRAID5となります。ディスクが1台故障したとしてもデータは保持され、大きなボリュームサイズを確保することが可能です。複数のディスクから読み込みするためReadのパフォーマンスがアップしますが、パリティー情報の書き込みが発生するため、Writeのパフォーマンスが低下します。ハードウェアのRAIDコントローラーでは、Writeのパフォーマンス低下を抑えるために、ライトバックというキャッシュメモリを利用したパフォーマンス対策を行っていますが、OSレベルのソフトウェアRAIDでは実現できていません。 DiskPartをPowerShellから使うには 各RAIDはWindows Serverの「ディスクの管理」から構築できますが、コマンドを利用することもできます。PowerShellではRAID関係のコマンドは提供されていないので、DiskPartを使って構築することになります。PowerShellからDiskPartを呼び出す場合は以下のようになります。 @"select disk 4convert dynamicselect disk 5convert dynamicselect disk 4select volume Eadd disk 5"@ | DiskPart RAID1（ミラー）のボリュームを作成するサンプルです。ポイントとしては、DiskPartで実行するコマンドをヒア文字列で作成して、パイプラインでDiskPartに引き渡す部分となります。 記憶域プール 記憶域プールの詳細についても、すでに様々な記事で詳しく紹介されているので、ここでは概要だけ紹介します。Windows Server 2012から利用できるようになった記憶域プールは、OSレベルで構築する新しいディスクシステムです。仮想化の技術を応用し、仮想ディスクベースで構成されます。複数の物理ディスクに跨ってデータを分散し、冗長性、拡張性、パフォーマンスに優れたディスクシステムを提供します。 これまで「ディスクの管理」から行っていたような構築管理が、サーバーマネージャーやPowerShellで行うことができるようになっています。RAIDボリュームのような冗長性を持たせつつ、さらに障害対策機能も向上しています。また、仮想化ならではの機能で、実際の物理ディスク以上の容量を確保したボリューム作成が可能で、オンラインで後からディスクを追加することができるなど、管理のしやすさ、パフォーマンスの向上も実現しています。 記憶域プールでは「シンプル」「ミラー」「パリティー」といった記憶域のレイアウトを選択することができ、RAIDボリューム以上の障害対策を利用することが可能です。 記憶域のレイアウトの簡単な説明をしておきます。 ・シンプルは、RAID0のように高いパフォーマンスでディスクを無駄なく利用することができますが、障害対策機能を持っていませんので、物理ディスクに障害が発生した場合、データを失うことになります。 記憶域のレイアウト シンプル ・ミラーはRAID1同様に2台のディスクでデータを二重化して保存しているので、障害対策も問題ありません。さらなる障害対策として、同じデータを3か所に保存しておくといった3方向ミラーという構成も選択可能です。3方向ミラーの場合、最低5台の物理ディスクが必要で、2台までの故障に対応できますが、その分ディスク容量の利用効率は低くなり、コストがかかります。 記憶域のレイアウト ミラー ・パリティーは、RAID5のようにデータを3台以上のディスクに分散して保存して、パリティー領域にデータ保存情報を確保するので、ミラーよりもディスク容量の利用効率は良くなっています。パリティー情報の書き込みが発生するため、書き込み速度が遅くなる傾向があります。 記憶域のレイアウト パリティー 記憶域プールの作成 記憶域プールは、サーバーマネージャーもしくはPowerShellから作成することができます。まずはサーバーマネージャーを使って記憶域プールを作成してみましょう。「サーバーマネージャー」 - 「ファイルサービスと記憶域サービス」 - 「記憶域プール」を選択します。右上の「タスク」から「記憶域プールの新規作成」を選択してウィザードを起動します。 「記憶域プール名」を設定して、利用していない物理ディスクを3台選択します。 ディスクの選択 記憶域プールが作成されました。 記憶域プールの作成完了 次に、作成した記憶域プール内に仮想ディスクを作成します。仮想ディスクの「タスク」から「仮想ディスクの新規作成」を選択します。 仮想ディスクの新規作成 記憶域プールが複数ある場合は、仮想ディスクを作成する記憶域プールを選択して、ウィザードを起動します。 記憶域プールの選択 仮想ディスク名を設定します。エンクロージャの回復性の指定は、ブレードサーバーなどを利用する場合にブレードのモジュールなどを物理的に分けている場合に指定する項目となります。エンクロージャがない場合、チェックボックスは無効になっているのでこのまま次に進みます。 エンクロージャの設定 記憶域のレイアウト、RAID0と比較するため、今回は「Simple」を選択します。 記憶域のレイアウトの選択 プロビジョニングの種類の指定では、仮想ディスクの初期状態を指定します。 Hyper-Vで利用する仮想ハードディスクのvhdxファイルと同様に、「最小限」は利用した分だけ実容量を確保する容量可変の仮想ディスクです。「固定」は先にボリュームの実容量すべてを確保しておく仮想ディスクとなります。記憶域プールを利用すると、利用当初からすべての実容量を確保しておく必要がないという、仮想化ならではの利便性があります。足りなくなったら後から物理ディスクを追加することが可能です。 ここでは「最小」を選択します。 プロビジョニングの種類の指定 仮想ディスクのサイズを指定します。先ほど作成したRAID0と比較するため、同じサイズで作成しておきます。 仮想ディスクのサイズの指定 仮想ディスクが作成されました。 仮想ディスクの作成完了 「閉じるボタン」をクリックすると、引き続き「新しいボリュームウィザード」が自動的に起動します。これ以降はこれまで利用していた「ディスクの管理」ツールでボリュームを作成する手順と同じです。 新しいボリュームウィザード ボリュームを作成するディスクを選択します。先ほど作成した仮想ディスクがリストに追加されています。 ディスクの選択 「ディスクの管理」ツールから確認すると、仮想ディスクが1台の物理ディスクとして認識されているのが確認できます。 ディスクの管理から確認 ボリュームサイズを指定します。ここでは最大サイズを指定します。 ボリュームサイズの指定 ドライブ文字を割り当てます。フォルダとして割り当てることも可能です。 ドライブ文字の割り当て ファイルシステムの指定で、ファイルフォーマットを指定します。 ファイシステムの選択 「ディスクの管理」ツールのボリューム作成ウィザードと異なる点は、データ重複除去の設定が併せてできる点です。 データ重複除去の設定 ボリュームが作成されました。 ボリューム作成の完了 「ディスクの管理」ツールからも確認できます。 ディスクの管理からボリュームの確認 早速、パフォーマンスをチェックしてみましょう。先ほど作成したRAID0と同等のパフォーマンスとなっています。 記憶域プールSimple RAID0 ここまでだと、記憶域プールのSimpleとこれまでの「ディスクの管理」から作成したRAID0（ストライプ）の違いは無いように思えますが、記憶域プールの利点はここからになります。 先ほど3台の物理ディスクで記憶域プールを作成しました。「ディスクの管理」ではすでに物理ディスク3台分の容量でボリュームを作成しているので、それ以上のボリュームは作成できません。記憶域プールでは仮想ディスクベースでボリュームを作成しているため、最小の容量でボリュームを作成でき、実際に利用していないディスクのスペースにさらにボリュームを作成することが可能です。いわゆるオーバーコミットと呼ばれている技術です。実際に利用された分だけ物理ディスクが消費されるので、初めは最小のコストでパフォーマンスを落とすことなくスタートすることができます。ディスク領域が足りなくなってきたら、記憶域プールに物理ディスクを追加していきます。 このキャプチャー画像は、物理ディスク3台分の記憶域プールの中に、物理ディスク6台分に相当する容量で仮想ディスクを作成して、2つのボリュームとして利用している状態です。これまででは実現できなかったディスクシステムを構成できるのが、記憶域プールのメリットとなります。 効率的なディスクの利用が可能な記憶域プール ただし、同じ物理ディスク上に複数の記憶域プールを作成した場合は、ディスクの故障によるデータ消失のリスクが高くなりますので、障害対策として万全を期す場合には記憶域プールごとに仮想ディスクを割り当てることをお勧めします。 ※仮想ディスクの削除不要となった仮想ディスクを削除する場合は、作成しているボリュームを先に削除してから、仮想ディスクを削除する必要があります。 ボリュームの削除・仮想ディスクの削除 続いて、記憶域プールのMirrorとParityも同様に作成してパフォーマンスを見てみましょう。記憶域プールMirrorの場合は、Readのパフォーマンスがほぼ1台の物理ディスクと同様となっています。RAID1のほうがReadについてはパフォーマンスが良いようです。 記憶域プールMirror RAID1 記憶域プールのParityでは、RAID5の弱点であったWriteのパフォーマンスが向上しています。 記憶域プールParity RAID5 PowerShellによる記憶域プールの作成 サーバーマネージャーから記憶域プールの作成方法を紹介しましたので、次にPowerShellで記憶域プールを作成する方法を紹介します。 まずは、物理ディスク一覧でDeviceIdを確認します。このDeviceIdをキーとして記憶域プールを作成していきます。 (Get-PhysicalDisk -CanPool $True) | Select DeviceidDeviceid--------7131242381091114165 物理ディスクのDeviceId 2,3,4を使って記憶域プールを作成します。記憶域のレイアウトはSimpleです。 $PhysicalDisks = (Get-PhysicalDisk -CanPool $True) | Where {($_.Deviceid -eq 2) -Or ($_.Deviceid -eq 3) -Or ($_.Deviceid -eq 4)}$StragePoolName = "SP01"$VirtualDiskName = "VD_Simple"$Layout = "Simple"New-StoragePool -FriendlyName $StragePoolName -StorageSubsystemFriendlyName (Get-StorageSubSystem).FriendlyName -PhysicalDisks $PhysicalDisks -ResiliencySettingNameDefault $Layout -ProvisioningTypeDefault Thin -Verbose 仮想ディスクを作成して、ボリュームを作成します。 $DriveLetter = "E"New-VirtualDisk -FriendlyName $VirtualDiskName -StoragePoolFriendlyName $StragePoolName -Size 465GB -ProvisioningType Thin | Initialize-Disk -PassThru | New-Partition -UseMaximumSize -DriveLetter $DriveLetter | Format-Volume -Confirm:$falseDriveLetter FileSystemLabel FileSystem DriveType HealthStatus OperationalStatus SizeRemaining Size----------- --------------- ---------- --------- ------------ ----------------- ------------- ----E NTFS Fixed Healthy OK 464.73 GB 464.87 GB PowerShellを使えば、記憶域プールから仮想ディスク、ボリュームの作成まで一気に完了します。 仮想ディスクの削除と、記憶域プールの削除は以下となります。 Get-VirtualDisk -FriendlyName $VirtualDiskName | Remove-VirtualDisk -Confirm:$falseGet-StoragePool -FriendlyName $StragePoolName | Remove-StoragePool -Confirm:$false RAID10・RAID50の構築は可能か？ RAIDと記憶域プールの解説はここまでとして、今回の本題に移りたいと思います。これまで見てきたように、Windows Server 2019では、「ディスクの管理」からRAID0、1、5の構成が作成できました。記憶域プールでもRAID0、1、5相当の障害対策を踏まえたディスクシステムを構築することが可能となっていました。RAIDではさらにパフォーマンスのアップとディスクの障害対策を万全にするために、RAID10（1+0）、RAID50（5+0）と呼ばれるディスク構成を採用することが可能です。RAID1、RAID5の冗長性とRAID0のパフォーマンスを合わせて、RAID10は物理ディスクを2台1組としてRAID1のペアを作成し、複数台ストライプとして並べたものです。RAID50は3台以上の物理ディスクを一組としてRAID5の構成をペアとして作成し、複数台ストライプとして並べたものです。 RAID10・RAID50 RAID10とRAID50をWindow Serverで実現するためにはどのように構成すべきか考えてみましょう。 記憶域プールで作成した仮想ディスクは、Windows Serverからは1つのディスクとして認識されています。 ディスクとして確認できる仮想ディスク すでにこの状態で、記憶域プールでMirrorもしくはParityとして仮想ディスクが作成されていれば、これを複数作ってRAID0（ストライプ化）とすることで、RAID10とRAID50を構築可能と考えられます。先にも述べましたが、複数のディスクで構成される記憶域プール内に、複数の仮想ディスクを作成した場合、見た目は冗長性が確保されているように見えますが、実際の障害対策としては不十分となります。RAID10とRAID50を構築する場合でも、物理ディスクごとに記憶域プールをきちんと作り分けて仮想ディスクを作成する必要があります。 従って、RAID10の場合に必要な物理ディスクは最低でも4台、RAID50の場合は6台となります。RAID0にする組み合わせが増えれば増えるほど、パフォーマンスアップが期待できますし、記憶域のレイアウトを3方向のMirrorにした場合などは最低でも10台の物理ディスクが必要となります。 記憶域プールを利用したRAID10・RAID50 RAID10とRAID50のディスクシステムをPowerShellで一気に構築してみましょう。 まずはRAID10から。 $PhysicalDisks = (Get-PhysicalDisk -CanPool $True) | Where {($_.Deviceid -eq 2) -Or ($_.Deviceid -eq 3)}$StragePoolName = "SP01"$VirtualDiskName = "VD01"$Layout = "Mirror"New-StoragePool -FriendlyName $StragePoolName -StorageSubsystemFriendlyName (Get-StorageSubSystem).FriendlyName -PhysicalDisks $PhysicalDisks -ResiliencySettingNameDefault $Layout -ProvisioningTypeDefault Thin -VerboseNew-VirtualDisk -FriendlyName $VirtualDiskName -StoragePoolFriendlyName $StragePoolName -Size 465GB -ProvisioningType Thin | Initialize-Disk -PassThru$DiskNo1 = (Get-Disk -FriendlyName $VirtualDiskName).Number$PhysicalDisks = (Get-PhysicalDisk -CanPool $True) | Where {($_.Deviceid -eq 4) -Or ($_.Deviceid -eq 5)}$StragePoolName = "SP02"$VirtualDiskName = "VD02"$Layout = "Mirror"New-StoragePool -FriendlyName $StragePoolName -StorageSubsystemFriendlyName (Get-StorageSubSystem).FriendlyName -PhysicalDisks $PhysicalDisks -ResiliencySettingNameDefault $Layout -ProvisioningTypeDefault Thin -VerboseNew-VirtualDisk -FriendlyName $VirtualDiskName -StoragePoolFriendlyName $StragePoolName -Size 465GB -ProvisioningType Thin | Initialize-Disk -PassThru$DiskNo2 = (Get-Disk -FriendlyName $VirtualDiskName).Number@"select disk $DiskNo1convert dynamicselect disk $DiskNo2convert dynamiccreate volume stripe disk=$DiskNo1,$DiskNo2format fs=ntfs quickassign letter=E"@ | DiskPart 2つの記憶域プールにMirrorの仮想ディスクをそれぞれ作成しました。 2つの記憶域プールに2つのMirrorを作成 EドライブとしてRAID0を構築しています。 2つの仮想ディスクでRAID0を構成 パフォーマンスも良好です。 RAID10のパフォーマンス 続いてRAID50です。 $PhysicalDisks = (Get-PhysicalDisk -CanPool $True) | Where {($_.Deviceid -eq 6) -Or ($_.Deviceid -eq 7) -Or ($_.Deviceid -eq 8)}$StragePoolName = "SP03"$VirtualDiskName = "VD03"$Layout = "Parity"New-StoragePool -FriendlyName $StragePoolName -StorageSubsystemFriendlyName (Get-StorageSubSystem).FriendlyName -PhysicalDisks $PhysicalDisks -ResiliencySettingNameDefault $Layout -ProvisioningTypeDefault Thin -VerboseNew-VirtualDisk -FriendlyName $VirtualDiskName -StoragePoolFriendlyName $StragePoolName -Size 465GB -ProvisioningType Thin | Initialize-Disk -PassThru$DiskNo1 = (Get-Disk -FriendlyName $VirtualDiskName).Number$PhysicalDisks = (Get-PhysicalDisk -CanPool $True) | Where {($_.Deviceid -eq 9) -Or ($_.Deviceid -eq 10) -Or ($_.Deviceid -eq 11)}$StragePoolName = "SP04"$VirtualDiskName = "VD04"$Layout = "Parity"New-StoragePool -FriendlyName $StragePoolName -StorageSubsystemFriendlyName (Get-StorageSubSystem).FriendlyName -PhysicalDisks $PhysicalDisks -ResiliencySettingNameDefault $Layout -ProvisioningTypeDefault Thin -VerboseNew-VirtualDisk -FriendlyName $VirtualDiskName -StoragePoolFriendlyName $StragePoolName -Size 465GB -ProvisioningType Thin | Initialize-Disk -PassThru$DiskNo2 = (Get-Disk -FriendlyName $VirtualDiskName).Number@"select disk $DiskNo1convert dynamicselect disk $DiskNo2convert dynamiccreate volume stripe disk=$DiskNo1,$DiskNo2format fs=ntfs quickassign letter=F"@ | DiskPart 2つの記憶域プールにParityの仮想ディスクをそれぞれ作成しました。 2つの記憶域プールに2つのParityを作成 FドライブとしてRAID0を構築しています。 2つの仮想ディスクでRAID0を構成 記憶域プールのParityよりもパフォーマンスが向上しています。 RAID50のパフォーマンス 以上、記憶域プールのMirrorとParityの障害対策と、RAID0のパフォーマンスをうまく組み合わせることができました。物理ディスクの台数と障害対策、パフォーマンスを考慮すると、RAID10のバランスが良い結果となっています。RAID50は書き込みの機会が多いバックアップ領域などの利用に適しているようです。RAID0で構成する仮想ディスクの数を増やすことでさらなるパフォーマンスアップも期待できます。さらに、記憶域プールでSimpleの仮想ディスクを作成し、「ディスクの管理」でRAID1やRAID5を構成して、RAID01（0+1）、RAID05（0+5）など逆の構成や障害対策にすぐれたRAID11（1+1）など自由に組み合わせることも可能です。このように、Windows Server 2019では、これまでのソフトウェアRAIDと記憶域プールを組み合わせることで、障害対策にすぐれ、パフォーマンスも向上させることができるディスクシステムを構築することが可能です。PowerShellを使えば簡単に構築可能ですので、利用するハードウェア環境でこれらの構成を試して、最適なディスクシステムを見つけてみましょう。

Windows Server 2019が登場 2018年秋、Windows Serverの新しいバージョンである、Windows Server 2019が公開されました。見た目はほぼWindows Server 2016と変わりは無いものの、サーバー用途として玄人受けする新機能が追加されています。その中でも注目しているのはストレージ関連です。Windows Serverでは、新しいストレージ関連の機能がWindows Server 2012 R2頃から追加され続けてきました。記憶域プールやスケールアウトファイルサーバ（SOFS）、記憶域スペースダイレクト（S2D）など、パフォーマンスや使い勝手の向上、冗長性などを踏まえつつ小規模から大規模まで展開できるような柔軟なストレージシステムを構築することが可能となっています。今回は、Windows Server 2019でサーバー1台でも利用可能なストレージ関係の機能を確認しつつ、注目している新機能の使いどころを考えてみたいと思います。 NTFSとReFS Windowsのファイルフォーマット形式としてサポートされているのは、FAT32、exFAT、NTFS、ReFSとなっています。 FAT32とexFATは一昔前のWindowsで採用されていたフォーマット形式で、最新のOS環境ではあまり利用されていません。Windows Serverを単体で利用する場合はNTFSを利用することが多いと思います。 では、ReFS（Resilient File System）とはどういったファイルフォーマットなのか、NTFSと比較してその特徴を理解してみましょう。特に注目しておきたい機能の差は以下となります。 NTFSReFS最大ボリュームサイズ256 TB（テラバイト）4.7 ZB（ゼタバイト)OSの起動領域〇×ボリュームの拡大〇〇ボリュームの縮小〇×重複除去〇〇ファイルの圧縮〇×ファイルの暗号化〇×BitLockerによる暗号化〇〇ディスク クォータ〇×リムーバブルメディアのサポート〇×固定仮想ディスクファイル作成の高速化×〇ブロックの複製×〇ミラーリングによって高速化されたパリティ×〇ボリュームオンラインでのデータ修復×〇 ReFSの特徴としては、 ・大容量のデータ、ボリュームを扱えるようになった。 ・NTFSではファイルの破損を回復するためにCheckDiskコマンドを実行してサーバーの再起動が必要でしたが、ReFSではオンラインでデータの修復が可能。 ・冗長性と拡張性の高い「記憶域スペースダイレクト」との組み合わせにより、ミラーリングによって高速化されたパリティを実現し、高パフォーマンスで容量効率の高いストレージシステムが構築できるようになった。 といった点が上げられます。 NTFSとの互換性を維持しつつ、効率的に大容量のデータを扱うための新機能がReFSで実現されています。大規模なストレージを構成するファイルサーバーや、バックアップサーバーのデータ領域などはReFSを採用すべきと考えます。 ReFSフォーマット 仮想ハードディスク　容量固定と容量可変 Windows ServerやHyper-Vでは仮想ハードディスクを利用することができます。Hyper-Vの仮想マシンやサーバーのドライブにマウントして利用する場合、仮想ハードディスクは容量固定と容量可変の2種類を選択可能です。以前は容量固定の方がパフォーマンス的に有利といわれていましたが、最近では、容量固定、容量可変のパフォーマンスの差はほぼ無いといっていいほどになっています。仮想ハードディスクのフォーマット形式も、物理サーバーと同様にNTFS、ReFSなど選択が可能です。では、Windows ServerやHyper-V上の仮想マシンで仮想ハードディスクを利用する場合、ファイルフォーマットと仮想ハードディスクの種類で最適な組み合わせはどれになるのか、実際に Crystal Disk Mark を使ってベンチマークを取って検証してみましょう。参考までにホストサーバー上の物理ドライブでパーティションを作成し、E・FドライブとしてNTFS、ReFSでそれぞれフォーマットしてベンチマークを取った結果がこちらです。NTFSでフォーマットした方が、若干ですがパフォーマンスが良いようです。 ホストサーバー上のディスク構成 E・Fそれぞれのドライブ内で仮想マシンを作成します。仮想マシンにはデータディスクとして10GBの仮想ハードディスクを作成し、追加ドライブとして接続しています。 組み合せとしては、D:\ 容量可変 + NTFSE:\ 容量固定 + NTFSF:\ 容量可変 + ReFSG:\ 容量固定 + ReFSを、それぞれホスト上のEドライブ（NTFS）とFドライブ（ReFS）上で2つの仮想マシンを同様に作成しています。 仮想マシンのディスク構成 2つの仮想マシンと4つのドライブ、それぞれに対してベンチマークを取った結果がこちらです。 NTFS上の仮想マシン ReFS上の仮想マシン 以上の測定結果から分かることは、 ・仮想マシンのベースとなるホストサーバー上の物理ディスクでのファイルフォーマットは、NTFS、ReFSではパフォーマンスにおいて大きな差は確認できない。 ・仮想ハードディスクは容量固定、容量可変どちらでもパフォーマンスの差は確認できない。 ・仮想ハードディスクの場合、ReFSフォーマットでデータ書き込みに無視できないパフォーマンスの低下が確認できる。 となります。 以上を踏まえると、サーバーの物理ディスクに関してはNTFS、ReFSどちらのフォーマットでもパフォーマンス的な差はなく、仮想マシンで仮想ハードディスクを利用する場合はNTFSフォーマットを選択すべきと考えられます。 Hyper-VでReFSを利用する利点 Hyper-VでReFSを利用する場合の利点として2つあげることができます。 1つ目は、容量固定の仮想ハードディスクの作成が速いことです。サンプルコードを使って確認してみましょう。 上記で利用したHyper-Vのホストサーバー上で、NTFSでフォーマットしたEドライブと、ReFSでフォーマットしたFドライブにそれぞれ10GBの容量固定の仮想ハードディスクを作成して、その処理時間を計測しています。NTFSでは12秒を要していた仮想ハードディスクの作成がReFSでは1秒で完了しています。VDIやホスティングなど大量の仮想ハードディスクを作成する場合などには、この速さはとても大きな利点となります。 (Measure-Command {New-VHD -Path E:\NTFS_10GB.vhd –Fixed –SizeBytes 10GB}).TotalSeconds12.0480127 (Measure-Command {New-VHD -Path F:\ReFS_10GB.vhd –Fixed –SizeBytes 10GB}).TotalSeconds1.0446116 2つ目は、ReFS上の容量固定の仮想ハードディスクでチェックポイントを作成した場合、チェックポイントの削除の際に行われる仮想ハードディスクの結合処理が速いことです。（容量可変でチェックポイントを削除した場合は、結合元の仮想ハードディスクファイルのサイズ変更が発生するため、パフォーマンスは容量固定の場合より劣ります。）Hyper-Vのホストサーバーで、NTFSでフォーマットしたEドライブとReFSでフォーマットしたFドライブ上に、それぞれ容量固定200GBの仮想ハードディスクで仮想マシンを作成します。検証のために2つの仮想マシンでチェックポイントを作成します。 2つの仮想マシンを作成してチェックポイントを作成 次に、2つの仮想マシンそれぞれにログインして、仮想マシンのCドライブ内に検証用で100GBの大きなファイルを作成します。 仮想マシンの中に100GBのファイルを作成 この状態でチェックポイントの削除（ファイルの結合）を行ってみましょう。ホストサーバーのイベントログ「Hyper-V-VMMS」には、ファイルの結合が開始されてから完了するまでのログが出力されています。NTFS上の仮想マシンでは、ファイルの結合が完了するまでに”2分42秒”時間を要しています。 NTFSファイル結合開始 NTFSファイル結合完了 一方、ReFS上の仮想マシンでは、”1秒“で完了しているのが確認できます。 ReFSファイル結合開始 ReFSファイル結合完了 このようにReFSはHyper-V利用時にも大きなメリットを与えてくれます。ホストサーバーではReFS上のドライブに作成された仮想マシンであっても、仮想マシン自体のファイルフォーマットは任意に選択が可能です。ホストサーバーではReFS、仮想マシンではNTFSの利点を享受して仮想マシンを作成することも可能です。 重複除去 重複除去は、簡単にいえば、ディスク内に存在するファイルの中で、同じファイルをひとまとめにして容量を削減する機能です。重複除去機能はWindows Server2012ですでに搭載されていましたが、最新のWindows Server 2019の重複除去では、重複除去率とパフォーマンスが改善されており、ファイル単位ではなくバイナリのデータ単位で重複を検出して除去するため、大幅に重複除去率が向上しています。 NTFSフォーマットで利用可能なファイルの圧縮と機能的には似ている部分がありますが、ファイル圧縮は特定のフォルダに対しての書き込み時に実行されるため、管理者側で明示的に対象フォルダを指定する必要がありました。重複除去は一度設定すればボリューム内のすべてのファイルが対象となり、定期的に実行されます。書き込みごとに圧縮される場合、継続的なパフォーマンスの懸念がありますが、重複除去はスケジュール設定が可能なため、慢性的なパフォーマンスへの影響を回避することができます。 さらに、Windows Server 2019ではファイルの圧縮がサポートされていない、ReFSフォーマットでの重複除機能が利用可能となりました。これによって、大容量のボリュームでパフォーマンスを維持しつつ、高いファイルの収容率を実現できるようになります。 同様のファイルが多数存在するような企業内のファイルサーバーや、VDIとして仮想マシンのテンプレートが多く利用されている場合など、重複除去の効果が期待できると考えられます。 90％という驚異的な重複除去率を実現 重複除去を行った場合でも、ディスクのパフォーマンスは通常と遜色ないことが確認できます。 検証結果を踏まえて Windows Server 2019で利用できるストレージ機能の使いどころとしては、以下が考えられます。・ReFSは大容量のファイルサーバーやバックアップサーバーの物理ドライブのファイルフォーマットとして積極的に採用すべきオンライン状態で破損データの回復を図れる点や、重複除去機能による収容効率のアップ、「記憶域スペースダイレクト」との組み合わせによるミラーリングによって高速化されたパリティは、高いパフォーマンスと収容効率を必要とするデータの保存場所として最適と考えられます。 ・Hyper-V環境においてReFSによるパフォーマンスアップを期待する場合は、容量固定の仮想ハードディスクの利用が最適ホストサーバーでReFSによってフォーマットされたボリューム上に仮想マシンを展開することで、ディスクパフォーマンスのアップが期待できます。この場合、重複除去機能と併用することでサーバー当たりの収容効率を高めることが可能です。仮想マシン自体はこれまで通り、NTFSでのフォーマットでの利用が最適と考えられます。 以上、Windows Server 2019のストレージ関連の機能を確認しつつ、その使いどころを考えてみました。 高価なストレージ機材を揃えるまでもなく、Windows Server 2019には、パフォーマンスや障害対策に優れたストレージシステムを構築する機能がすでに搭載されています。 新しいWindows Serverには玄人受けする機能がたくさん盛り込まれていますので、ぜひお試しください。

GMOインターネットが提供するVPSサービス「ConoHa」のAPIを使って、オリジナルコマンドを使ったサーバー管理方法を3回に渡ってご紹介するレポート。最終回のVol.3では、仮想マシンの作成コマンドについてご紹介します。 はじめに 引き続きConoHaをPowerShellでどうにかすべく、オリジナルコマンドを作成していきましょう。サーバー一覧の取得、サーバーの起動・停止コマンドが完成しているので、今回はサーバー（仮想マシン）の作成コマンドを作成しましょう。 $apiUser = "gncu12345678" $password = "paSSword123456#$%" $tenantId = "487727e3921d44e3bfe7ebb337bf085e" $script:token = "" Function Get-cTokenHeader(){ $body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}' $tokenUrl = "https://identity.tyo1.conoha.io/v2.0/tokens" If($script:token){ $expiresTime = Get-Date -Date $script:token.access.token.expires If ($expiresTime -lt (Get-Date)){ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } }Else{ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } $tokenId = $script:token.access.token.id Return @{"X-Auth-Token" = $tokenId} } Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET If($flavorId -eq $null){ $flavors = $result.flavors $objAry = @() ForEach($flavor in $flavors){ $id = $flavor.id $name = $flavor.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry }Else{ Return $result.flavor } } Function Get-cVM(){ Param( $Name ) $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $servers = $result.servers $objAry = @() ForEach($server in $servers){ $id = $server.id $tagName = $server.metadata.instance_name_tag $state = $server.status $flavorId = $server.flavor.id $flavor = Get-cFlavor $flavorId $vcpu = $flavor.vcpus $ram = $flavor.ram / 1024 $disk = $flavor.disk $ip = ($server.addresses.($server.addresses.PSObject.Properties.name) | ? version -eq 4).addr $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $tagName} $objPs | Add-Member -NotePropertyMembers @{State = $state} $objPs | Add-Member -NotePropertyMembers @{vCPU = $vcpu} $objPs | Add-Member -NotePropertyMembers @{Disk = $disk} $objPs | Add-Member -NotePropertyMembers @{Memory = $ram} $objPs | Add-Member -NotePropertyMembers @{IPAddress = $ip} $objAry += ($objPs | Select-Object ID, Name, State, Memory, Disk, vCPU, IPAddress) } $VM = $objAry If($Name -ne $null){ $VM = $VM | ? Name -eq $Name } If($VM -eq $null){ Write-Host ("""$Name"" という名前の仮想マシンが見つかりません。") -ForegroundColor Red }Else{ Return $VM } } Function Start-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } Function Stop-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-stop": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } Function Get-cImage(){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/images/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $images = $result.images $objAry = @() ForEach($image in $images){ $id = $image.id $name = $image.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry } Function New-cVM($name, $imageId, $flavorId, $adminPass){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers" $body = @" { "server": { "imageRef" : "$imageId", "flavorRef" : "$flavorId", "adminPass" : "$adminPass", "metadata": { "instance_name_tag": "$name" } } } "@ $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body Return $name } モジュールファイル「PSdeConoHa.psm1」に新しいコマンドを追加していきます。 イメージ一覧の取得 サーバー作成のコマンドの前に、コマンドのパラメーターとして必要となるサーバーイメージIDを取得するコマンドを作成しておきましょう。 API解説ページでcurlコマンドのサンプルコードを見てみましょう。 curl -i -X GET \-H "Accept: application/json" \-H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \https://compute.tyo1.conoha.io/v2/1864e71d2deb46f6b47526b69c65a45d/images/detail GETメソッドでリクエストURLに「テナントID」と「Server ID」を含めてAPIにサーバー情報を送信するだけなので簡単ですね。 PowerShellのInvoke-RestMethodコマンドで置き換えるとこのようになります。 Function Get-cImage(){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/images/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $images = $result.images $objAry = @() ForEach($image in $images){ $id = $image.id $name = $image.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry } $tokenHeader = Get-cTokenHeader：これまでと同様にトークンヘッダー情報を取得します。 $requestUrl = https://compute.tyo1.conoha.io/v2/$tenantId/images/detail：リクエストURLはこちらです。 $images = $result.images：Invoke-RestMethodコマンドの実行結果imagesの中にイメージの一覧情報が格納されています。 ForEach($image in $images)　～　Return $objAry：それぞれのイメージ情報からイメージIDとイメージ名を抜き出してPSCustomObjectに格納して戻り値としています。 実行すると、すべてのイメージ一覧が表示されます。サーバー作成時にはイメージのIDが必要となるので確認しておきましょう。 PS C:\> Get-cImageID Name-- ----b2e06d42-4c68-4792-87c4-e6faff3c5c0c vmi-drupal-8.4.2-centos-7.4-amd64-20gbae172d73-d16c-42b7-bc32-41b40ca40e63 vmi-drupal-8.4.2-centos-7.4-amd649b70032f-c486-4fd9-9e00-e7899d336406 vmi-minecraft-1.12.2-centos-7.495450a81-8194-4ff2-aab6-4f2595da56bb vmi-centos-7.4-amd64-20gb・・・ プラン一覧の取得 サーバーを作成するコマンドにもう1つ必要なパラメーターとして、プランIDがあります。以前、サーバー情報を取得する「Get-cVM」コマンドを作成した際に「Get-cFlavor」コマンドを作成して、サーバーに割り当てられているプラン情報（CPU、メモリ、HDD）を取得しました。このコマンドをサーバー作成に利用できるプラン一覧を取得できるように修正しましょう。 API解説ページでcurlコマンドのサンプルコードを見てみましょう。 curl -i -X GET \-H "Accept: application/json" \-H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \https://compute.tyo1.conoha.io/v2/1864e71d2deb46f6b47526b69c65a45d/flavors 「Get-cFlavor」コマンドでは、URLの最後にサーバーIDを指定することで、割り当てられているプラン情報を取得していましたが、サーバーIDを指定しない場合は、プラン一覧を取得できるようです。「Get-cFlavor」コマンドを以下のように修正します。 Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET If($flavorId -eq $null){ $flavors = $result.flavors $objAry = @() ForEach($flavor in $flavors){ $id = $flavor.id $name = $flavor.name $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $name} $objAry += $objPs } Return $objAry }Else{ Return $result.flavor } } If($flavorId -eq $null)：flavorIdを指定していない場合はプラン一覧を取得します。 $flavors = $result.flavors：Invoke-RestMethodコマンドの実行結果flavorsの中にプラン一覧が格納されています。 ForEach($flavor in $flavors)　～　Return $objAry：それぞれのプラン情報からプランIDとプラン名を抜き出してPSCustomObjectに格納して戻り値としています。 Return $result.flavor：flavorIdが指定されている場合は、これまで同様該当するプラン情報を戻り値としています。 実行すると、すべてのプラン一覧が表示されます。サーバー作成時にはプランのIDが必要となるので確認しておきましょう。 PS C:\> Get-cFlavorID Name-- ----294639c7-72ba-43a5-8ff2-513c8995b869 g-2gb3aa001cd-95b6-46c9-a91e-e62d6f7f06a3 g-16gb62e8fb4b-6a26-46cd-be13-e5bbf5614d15 g-4gb7eea7469-0d85-4f82-8050-6ae742394681 g-1gb965affd4-d9e8-4ffb-b9a9-624d63e2d83f g-8gba20905c6-3733-46c4-81cc-458c7dca1bae g-32gbc2a97b05-1b4b-4038-bbcb-343201659279 g-64gbd92b02ce-9a4f-4544-8d7f-ae8380bc08e7 g-512mb サーバーの作成 ConoHaのコントールパネルでは、「サーバーの追加」メニューを表示するといくつかの選択項目があり、細かくサーバーの仕様を決めることができるようになっています。 ConoHa コントールパネル API解説ページを見てみましょう。 数多くのパラメーターがありますが、サーバーを作成する場合に必要な最低限の情報としては、X-Auth-Token、tenant_id、imageRef、flavorRef、adminPass　となっています。トークンとテナントIDはこれまで同様なので、イメージID（imageRef）とプランID（flavorRef）、管理者のパスワードが必要となります。イメージIDとプランIDは先ほど作成した「Get-cImage」と「Get-cFlavor」コマンドで確認しておきましょう。さらに、作成するサーバー名を指定しておきたいので、instance_name_tagも設定しておきましょう。 ParameterValueStyleDescriptionX-Auth-TokenUserトークンheaderトークンIDtenant_idURIテナントIDimageRefplainimage 参照先。対象 image の UUID を指定flavorRefplainVMプラン(flavor) の UUID を指定adminPass (Optional)plainVMのrootパスワード 詳細は vmのrootパスワードについて を参照key_name (Optional)ssh key nameplainSSHキーを利用する場合に指定するsecurity_groups (Optional)security_groupオブジェクトplainkeyに”name“を、valueにセキュリティグループ名を指定する(以下のRequestJson参照)metadata (Optional)plainmetadata の key:value ペア。instance_name_tag (Optional)Default:VMに紐づくGlobalIPアドレスplainネームタグを入れる際に利用する。文字種：半角英数字、「 - 」、「 _ 」のみを許可。文字数：255文字以下block_device_mapping (Optional)Arraydeviceは１つのみマッピングできるvolume_id (Optional)plainアタッチしたいVolumeのIDを指定するvncKeymap (Optional)plainkeymap 設定user_data (Optional)base64 encode された スタートアップスクリプトplainbase64 encoded Cloud-Init script curlコマンドのサンプルコードを見てみましょう。サーバー名としてinstance_name_tagを使用する場合は、metadata指定時のJSON形式となるので、こちらとなります。 {　　　"server": {　　　　　"imageRef": "1f7bcc63-4a18-4371-85b1-bcdd4301ff31",　　　　　"flavorRef": "b60acd11-3fd5-46e1-9387-aae4737d49aa",　　　　　"adminPass":"72LY2hf38Kf84vCy4sUr",　　　　　"metadata": {　　　　　　　"instance_name_tag": "testtest"　　　　　}　　　}} POSTメソッドでリクエストURLに「テナントID」と「Server ID」を含めてAPIにサーバー情報を送信するのでhttps://compute.tyo1.conoha.io/v2/<テナントID>/servers/<サーバー ID>/serversとなります。POSTメソッドで送信するJSON形式のデータは「-d '{"server":・・・」となっている部分で、サーバー作成のパラメーターを指定しています。サーバーの起動コマンドなどと仕組みは同じです。instance_name_tagはmetadateに指定する必要があるので、子要素を追加して指定します。 以上を踏まえてサーバーを作成するコマンドはこのようになります。 Function New-cVM($name, $imageId, $flavorId, $adminPass){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers" $body = @" { "server": { "imageRef" : "$imageId", "flavorRef" : "$flavorId", "adminPass" : "$adminPass", "metadata": { "instance_name_tag": "$name" } } } "@ $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body Return $name } Function New-cVM($name, $imageId, $flavorId, $adminPass)：New-cVMというコマンド名で、引数として、サーバー名、イメージID、プランID、管理者パスワードを指定します。 $body：POSTメソッドで送信するデータをJSON形式の文字列で指定します。必要最低限の情報は、今回はimageRef、flavorRef、adminPassの3つと、instance_name_tagとなります。 $result = Invoke-RestMethod：Invoke-RestMethodコマンドを実行します。 Return $result.server.id：サーバーが作成された場合のサーバー名を戻り値としています。 コマンドを実行してみましょう。 PS C:\> $res = New-cVM "myVM_01" "b2e06d42-4c68-4792-87c4-e6faff3c5c0c" "294639c7-72ba-43a5-8ff2-513c8995b869" "72LY2hf38Kf84vCy4sUr"PS C:\> Get-cVM $resID : 2024b61d-51ae-4c39-b196-4b317493b356Name : myVM_01State : ACTIVEMemory : 2Disk : 50vCPU : 3IPAddress : 150.95.217.10 変数”$res”の中にはNew-cVMの実行結果として、サーバー名が取得できているので、そのままGet-cVMコマンドを使ってサーバーの状態を確認することができます。 コントロールパネルでもサーバーが作成されているのが確認できます。 ConoHa サーバーリスト API解説ページにはこの他にも、「SSHキー指定時」や「追加ディスク指定時」のJSONデータのサンプルが記載されているので、必要に応じてコマンドのパラメーターを変更してより細かい設定でサーバーを作成も可能です。 以上がサーバーの作成コマンドとなります。 ConoHaにはこれまで見てきたような基本的な機能の他にも、様々なことができるAPIが用意されています。全てをPowerShellのコマンドに置き換えるのは大変ですが、自身の必要とする機能を選択してパイプラインやオブジェクトなどPowerShellならではの使いやすさで、ConoHaのサーバー管理を実現してみてはいかがでしょうか。 今後も、時間の許す限りPowerShellでConoHaをどうにかするべく、色々なコマンドを作成していきたいと考えています。 コードサンプルはGitHubにて公開しています。https://github.com/InvokeV/PSdeConoHa

GMOインターネットが提供するVPSサービス「ConoHa」のAPIを使って、オリジナルコマンドを使ったサーバー管理方法を3回に渡ってご紹介するレポート。Vol.2では、モジュールファイルの配置やサーバーの起動と停止コマンドをご紹介します。 モジュールファイルの配置 作成したPowerShellのオリジナルコマンドは、モジュール化して保存しておくことで自動的に読み込まれて利用することができるようになります。PowerShellのモジュールファイルについては以前紹介していますので、ここではモジュールファイルの配置と作成方法だけを簡単に説明することとします。 Hyper-Vで作るコンテナ　新しい仮想マシンの使い方-Vol.3　開発環境を整える “C:\Users\\Documents\WindowsPowerShell\Modules”このフォルダ内に”PSdeConoHa”フォルダを作成します。さらにPSdeConoHaフォルダ内に”PSdeConoHa.psm1”モジュールファイルを作成します。この時、フォルダ名とファイル名は同じにする必要があります。 PowerShell ISEを管理者権限で実行して"C:\Users\\Documents\WindowsPowerShell\Modules\PSdeConoHa\PSdeConoHa.psm1"ファイルを開きます。前回作成した「PSdeConoHa.ps1」の中身をそのままコピーして貼り付けます。適切な値を先頭の$apiUser、$password、$tenantIdに代入して「Remove-Module *」コマンドを実行してモジュールを初期化しておきます。これで、自動的にモジュールが読み込まれてコマンドを利用することができるようになります。モジュールを修正した場合は、再度「Remove-Module *」コマンドを実行するようにします。 前回作成した「Get-cVM」コマンドを実行してみましょう。ConoHa上のサーバー情報が取得できればモジュールの配置は成功です。 コマンドの作成：サーバーの起動 以後は、モジュールファイル「PSdeConoHa.psm1」に新しいコマンドを追加していきます。最終的に作成するのは、今回はここまでです。 $apiUser = "gncu12345678" $password = "paSSword123456#$%" $tenantId = "487727e3921d44e3bfe7ebb337bf085e" $script:token = "" Function Get-cTokenHeader(){ $body = '{"auth":{"passwordCredentials":{"username":"' + $apiUser + '","password":"' + $password+'"},"tenantId":"' + $tenantId+'"}}' $tokenUrl = "https://identity.tyo1.conoha.io/v2.0/tokens" If($script:token){ $expiresTime = Get-Date -Date $script:token.access.token.expires If ($expiresTime -lt (Get-Date)){ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } }Else{ $script:token = Invoke-RestMethod $tokenUrl -Method POST -Body $body } $tokenId = $script:token.access.token.id Return @{"X-Auth-Token" = $tokenId} } Function Get-cFlavor($flavorId){ $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/flavors/$flavorId" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET Return $result.flavor } Function Get-cVM(){ Param( $Name ) $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/detail" $result = Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method GET $servers = $result.servers $objAry = @() ForEach($server in $servers){ $id = $server.id $tagName = $server.metadata.instance_name_tag $state = $server.status $flavorId = $server.flavor.id $flavor = Get-cFlavor $flavorId $vcpu = $flavor.vcpus $ram = $flavor.ram / 1024 $disk = $flavor.disk $ip = ($server.addresses.($server.addresses.PSObject.Properties.name) | ? version -eq 4).addr $objPs = New-Object PSCustomObject $objPs | Add-Member -NotePropertyMembers @{ID = $id} $objPs | Add-Member -NotePropertyMembers @{Name = $tagName} $objPs | Add-Member -NotePropertyMembers @{State = $state} $objPs | Add-Member -NotePropertyMembers @{vCPU = $vcpu} $objPs | Add-Member -NotePropertyMembers @{Disk = $disk} $objPs | Add-Member -NotePropertyMembers @{Memory = $ram} $objPs | Add-Member -NotePropertyMembers @{IPAddress = $ip} $objAry += ($objPs | Select-Object ID, Name, State, Memory, Disk, vCPU, IPAddress) } $VM = $objAry If($Name -ne $null){ $VM = $VM | ? Name -eq $Name } If($VM -eq $null){ Write-Host ("""$Name"" という名前の仮想マシンが見つかりません。") -ForegroundColor Red }Else{ Return $VM } } Function Start-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } Function Stop-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-stop": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } 最初に作成するのはサーバーの起動コマンドです。API解説ページを見てみましょう。 必要な情報としては、 ParameterValueStyleDescriptionX-Auth-TokenUserトークンheaderトークンIDtenant_idURIテナントIDserver_idServer IDplainサーバーID となっています。 「Userトークン」と「テナントID」はサーバー一覧の取得と同じです。サーバーを特定するための「Server ID」が今回は必要となります。「Server ID」は実は前回作成した「Get-cVM」コマンドですでに取得できるようにしているので、ここから参照するようにします。PowerShellでは他のコマンドで取得した情報をそのまま再利用できるので非常に便利です。 curlコマンドのサンプルコードを見てみましょう。 curl -i -X POST \-H "Accept: application/json" \-H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \-d '{"os-start": null}' \https://compute.tyo1.conoha.io/v2/1864e71d2deb46f6b47526b69c65a45d/servers/997d6052-4b17-4500-8d41-c08fb9667aae/action 今回はPOSTメソッドでリクエストURLに「テナントID」と「Server ID」を含めてAPIにサーバー情報を送信するのでhttps://compute.tyo1.conoha.io/v2/<テナントID>/servers/<サーバー ID>/action　となります。ポイントはPOSTメソッドでJSON形式のデータを送信するということです。curlコマンンドのサンプルで「-d '{"os-start": null}'」となっている部分です。Invoke-RestMethodコマンドではPOSTするデータは「-Body」として取り扱います。$body = '{"os-start": null}' としてJSON形式のデータを変数に格納しておきます。 起動する仮想マシンはConoHaのコントロールパネルであらかじめ停止させておき、Get-cVMコマンドでID（” fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8”）を確認しておきます。 PS C:\> Get-cVM vps-2017-12-07-21-28ID : 0e3069ce-dee8-47b5-8009-990e065068f3Name : vps-2017-12-07-21-28State : SHUTOFFMemory : 1Disk : 50vCPU : 2IPAddress : 150.***.***.*** ここまでの情報をInvoke-RestMethodコマンドで置き換えるとこのようになります。 Function Start-cVM(){　　$serverId = “fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8”　　$tokenHeader = Get-cTokenHeader　　$requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action"　　$body = '{"os-start": null}'Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body} モジュールファイルに書き込みます。一度Remove-Module *　コマンドを実行して再読み込みをしてからテストしてみましょう。停止していた仮想マシンが起動状態になっていれば成功です。 PS C:\> Start-cVMPS C:\> Get-cVM vps-2017-12-07-21-28ID : 0e3069ce-dee8-47b5-8009-990e065068f3Name : vps-2017-12-07-21-28State : ACTIVEMemory : 1Disk : 50vCPU : 2IPAddress : 150.***.***.** ConoHaのREST APIを使ってInvoke-RestMethodコマンドからサーバーを起動することが確認できました。では、PowerShellらしく、コマンドを組み合わせて利用できるように修正していきます。このままではStart-cVMコマンドではサーバーIDを決め打ちして起動しているので、パラメーターを使って、任意のサーバーを起動できるようにしてみましょう。 Function Start-cVM(){　　Param(　　　 $VM ) $serverId = (Get-cVM $VM).ID $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}'Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body} パラメーターを使って、引数として＄VMを定義してサーバー名を指定できるようにしておきます。指定されたサーバー名を元に、Get-cVMを利用して、サーバーIDを取得できるようにしました。コマンドを実行してみましょう。 PS C:\> Start-cVM vps-2017-12-07-21-28PS C:\> Get-cVM vps-2017-12-07-21-28ID : 0e3069ce-dee8-47b5-8009-990e065068f3Name : vps-2017-12-07-21-28State : ACTIVEMemory : 1Disk : 50vCPU : 2IPAddress : 150.***.***.** パラメーターを使うことで使い勝手がよくなりました。さらに、PowerShellのコマンドであれば、パイプラインを利用できるようにしておきたいところです。パイプラインを利用することで、コマンドの実行結果をパラメーターとして受け取ることができるようになるので、コードが簡略化されます。 Function Start-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-start": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } 3 ：パラメーターの値をパイプラインから受け取るには、[Parameter(ValueFromPipeline=$True)]属性を変数にあらかじめ指定しておきます。 5-18 ：パイプラインで渡される値が複数の場合もあるので、すべてに対してProcessブロックで1つずつ処理をしていきます。 6 ：パイプラインでパラメーターに渡される値は文字列だけとは限りません。Get-cVMコマンドの実行結果であれば、PSCustomObject型の場合もあります。柔軟に対応できるようにSwitch文で分岐を作成しておきます。 7-8 ： PSCustomObject型の場合は、$VM変数には各種サーバーのプロパティーが格納されています。サーバーIDは$VM.IDで取得可能です。 14-17 ：String型（文字列）の場合はサーバー名ということで、これを引数としてGet-cVMコマンドを実行してサーバーIDを取得します。 85-88 ：サーバーIDが取得できれば、これまで同様、Invoke-RestMethodコマンドでConoHa APIを使ってサーバーを起動します。 パイプラインを使った場合はこのように一度にサーバーを起動することができます。 PS C:\> Get-cVM vps-2017-10-03-16-52 | Start-cVMPS C:\> Get-cVM vps-2017-10-03-16-52ID : fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8Name : vps-2017-10-03-16-52State : ACTIVEMemory : 4Disk : 50vCPU : 4IPAddress : 150.***.***.** コマンドの作成：サーバーの停止 サーバーの起動ができれば、もちろん停止コマンドも必要です。ConoHaにはサーバーの通常停止と強制停止があり、通常停止はシャットダウン処理、強制停止は電源OFFと同様のものになります。今回はサーバーの通常停止を行います。 API解説ページを見てみましょう。 必要な情報としては、 ParameterValueStyleDescriptionX-Auth-TokenUserトークンheaderトークンIDtenant_idURIテナントIDserver_idServer IDplainサーバID となっています。 サーバーの起動を異なるのはPOSTするJSONデータが{"os-stop": null}このようになるだけです。 Function Stop-cVM(){ Param( [Parameter(ValueFromPipeline=$true)]$VM ) Process{ Switch($VM.GetType().Name){ "PSCustomObject"{ $serverId = $VM.ID } "String"{ $serverId = (Get-cVM $VM).ID } } $tokenHeader = Get-cTokenHeader $requestUrl = "https://compute.tyo1.conoha.io/v2/$tenantId/servers/$serverId/action" $body = '{"os-stop": null}' Invoke-RestMethod $requestUrl -Headers $tokenHeader -Method POST -Body $body } } 16 ：Start-cVMからこの部分を変更します。 PS C:\> Get-cVM vps-2017-10-03-16-52 | Stop-cVMPS C:\> Get-cVM vps-2017-10-03-16-52ID : fe3ec4d2-1af7-4800-a2f8-6ceadd00f8d8Name : vps-2017-10-03-16-52State : ACTIVEMemory : 4Disk : 50vCPU : 4IPAddress : 150.***.***.** 以上でパイプラインにも対応したConoHaサーバーの起動と停止コマンドが完成です。 次回以降も引き続きPowerShellでConoHaをどうにかするべく、コマンドを作成していきましょう。 コードサンプルはGitHubにて公開しています。https://github.com/InvokeV/PSdeConoHa