はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業ではWorkspace ONEの要件を確認し、フリートライアル版の申込みを行いました。

今回の作業ではウィザードを用いてオンプレミスActive Directoryとの連携を行います。Active DirectoryからVMware Workspace ONE UEMへ、更にVMware Workspace ONE Accessへディレクトリユーザーやグループを連携します。

VMware AirWatch Cloud Connectorのインストール

Windows ServerにVMware AirWatch Cloud Connector(ACC)をインストールし、Active DirectoryからWorkspace ONE UEMにディレクトリユーザーやユーザーグループを同期します。

ACCはインターネットへの外部発信のみで機能するため、ACCをDMZに設置する必要もなく、またインバウンドトラフィックを許可するよう企業のファイヤーウォールを構成する必要もありません。

Workspace ONE UEMコンソールに管理者アカウントでログインします。トップページから[はじめに] > [Workspace ONE] > [セットアップを開始]を選択します。[ID およびアクセスの管理]セクションの[AirWatch Cloud Connector (ACC) およびディレクトリ] > [構成]を選択します。

[概要]ページが表示されます。[続行]をクリックします。

[AirWatch Cloud Connector (ACC)]ページが表示されます。ACCインストーラのダウンロードに際してパスワードを設定します。ACCインストーラは証明書を含んでおり、これを保護するためにパスワードを必要とします。

[AirWatch Cloud Connector (ACC) インストーラをダウンロード]をクリックします。ダウンロードが完了したら[続行]をクリックします。

ダウンロードしたACCインストーラを実行します。

(例) AirWatch Cloud Connector 20.8.0.6 Installer.exe

Windows Server 2019でのインストーラ実行時に[Windows protected your PC]ウィンドウが表示される際には、[More Info]をクリックし[Run Anyway]をクリックするとインストールを続行することができます。

インストラクションのステップに従ってACCのインストールを完了します。

重要: 最後にWindows Serverの再起動を促す[You must restart your system for the configuration changes made to AirWatch Cloud Connector to take effect. ]メッセージが表示されますが[No]を選択します。これは[AirWatch Cloud Connector (ACC)]ウィザードを完了するために必要な措置です。

Windows Serverの再起動を促す[You must restart your system for the configuration changes made to AirWatch Cloud Connector to take effect. ]メッセージが表示されますが[No]を選択します。これは[AirWatch Cloud Connector (ACC)]ウィザードを完了するために必要な措置です。

Workspace ONE UEMコンソールで、ウィザード画面を下方にスクロールし[続行]をクリックします。

AirWatch Cloud Connector (ACC) 接続テスト

[接続のテスト]をクリックします。[Cloud Connectorに到達しました]旨の表示があれば[続行]をクリックします。

ディレクトリ設定

Active Directoryへの接続情報を入力します。[保存]をクリックします。ドメインコントローラーに接続できない場合、ACCインストールWindows ServerがドメインコントローラーのFQDNを名前解決できること、ドメインコントローラーと通信可能であることを再確認ください。

Active Directory接続テスト

[接続のテスト]をクリックします。[正常に接続されました。]の表示があれば[保存]をクリックします。

[次のステップ（強く推奨）]が表示されますので[キャンセル]を選択します。

この表示はVMware Workspace ONE Access Connectorの構成についての説明です。本連載では省略しますが、別記事にて構成および移行手順を掲載予定です。

ここまでの設定でActive Directoryとの連携を行いました。

Active Directory Basicの構成

Active Directory Basicを構成し、Workspace ONE UEM経由でディレクトリユーザーやユーザーグループをActive DirectoryからWorkspace ONE Accessに同期します。

本構成は、検証を目的として素早く環境を立ち上げるための簡易構成です。本稼働構成ではWorkspace ONE Access Connectorを用いた構成が強く推奨されます。

[グループと設定] > [構成]を選択します。[構成に進む]をクリックします。

下方にスクロールしてWorkspace ONE Access をクリックします。

[構成]をクリックします。Active Directory Basicの[有効]をクリックします。

Workspace ONE Access管理者のユーザー名、管理者パスワードを入力します。[接続のテスト]をクリックします。正常に接続された旨の表示があれば[次へ]をクリックします。

ディレクトリ名を入力します。属性マッピング等は既定のまま[保存]をクリックします。[保存]をクリックします。

ディレクトリの同期が正常動作する旨の表示を確認します。

モバイルシングルサインオンのセットアップ

ゼロトラストセキュリティのキーコンポーネントのひとつ、加入デバイスからWorkspace ONE Accessへの証明書認証によるシングルサインオンを実現します。SCEPプロファイルによりAirWatch 認証局から発行される証明書をデバイスに配布します。Workspace ONE Accessの認証ポリシーも自動構成されます。

ウィザードの[モバイルシングルサインオン] > [構成]をクリックします。

[使用を開始する]をクリックします。

[続行]をクリックします。

[構成を開始]をクリックします。

1〜６まで構成が進捗したら[完了]をクリックします。

[閉じる]をクリックします。

Hubサービスの構成

デバイスのWorkspace ONE Intelligent Hubに対し、様々なサービスを提供するHub サービスを構成します。サービスには以下のようなものがあります。

• 統合アプリカタログ
• 従業員へのワークフロー通知
• 同僚や上長の検索
• バーチャルアシスタント
• 従業員セルフサービスのサポート

Workspace ONE Intelligent Hubは単なるMDMエージェントではなく、従業員の生産性を向上するために、様々な企業リソースへ簡単にアクセスするための[情報ハブ]として機能します。

ウィザードの[Workspace ONE Intelligent Hub] > [構成] をクリックします。

Hubサービスが表示されます。[起動]をクリックします。

Hubサービスが表示されます。[開始]をクリックします。

Hubサービスのホーム画面が表示されます。右上の[WORKSPACE OEN UEMに戻る]をクリックします。

認証ソースの変更

Hubサービスを最大限に活用するため、認証ソースをWorkspace ONE Accessに変更します。

Hubサービス画面を下方にスクロールし、[認証ソース] > [構成] をクリックします。

認証モード: [ベーシック]および[ディレクトリ]にチェックが入っていることを確認

Intelligent Hub の認証ソース: [WORKSPACE ONE ACCESS] を選択

[保存]をクリックします。

最後に、AirWatch Cloud Connector (ACC)インストール時に要求されていたWindows Serverの再起動を行います。

今回の作業ではActive Directoryとの連携を行いました。またActive DirectoryからWorkspace ONE UEMへ、更にWorkspace ONE Accessへディレクトリユーザーやグループの連携設定を行いました。

次回はActive Directoryのドメインユーザーを、Workspace ONE UEM/Accessのディレクトリユーザーとして追加します。

The post Windows 10モダンマネジメントガイド 第2回 オンプレミスActive Directoryとの連携 appeared first on VMware Japan Blog.

はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業ではActive Directoryとの連携を行い、ユーザーやグループの連携設定を行いました。

今回の作業ではオンプレミスActive DirectoryのドメインユーザーをVMware Workspace ONE UEMのディレクトリユーザーとして追加します。またActive Directoryの組織ユニット(OU)を、Workspace ONE UEMのユーザーグループとして追加します。最後にWorkspace ONE UEMのディレクトリユーザーやユーザーグループを、VMware Workspace ONE Accessに連携します。

ドメインユーザーの属性

Active DirectoryのドメインユーザーをWorkspace ONE UEMのディレクトリユーザーとして追加する際、[姓、名、電子メール]が必須の属性となります。属性がないと、ディレクトリユーザーとして追加に失敗する場合があります。

ディレクトリユーザーの追加

Active DirectoryのユーザーをWorkspace ONE UEMへユーザーとして追加します。Workspace ONE UEMにデバイス加入する際のユーザーアカウントとして利用されます。

Workspace ONE UEMコンソール トップページを表示します。[追加] > [ユーザー] を選択します。

セキュリティタイプで[ディレクトリ]をクリックします。ユーザー名にActive Directoryに存在するユーザー名を入力し[ユーザーを確認]をクリックします。Active Directoryユーザーがルックアップされるので[保存]をクリックします。

Workspace ONE UEMコンソールで [アカウント] > [ユーザー] > [リスト表示]を選択します。

Active DirectoryユーザーがWorkspace ONE UEMのディレクトリユーザーとして追加されていること、またユーザー名をクリックしユーザー詳細などを確認します。

ここまでの作業で、Active DirectoryのユーザーをWorkspace ONE UEMのディレクトリユーザーとして追加しました。

ユーザーグループの追加

Active Directoryの組織ユニット(OU)またはセキュリティグループをWorkspace ONE UEMのユーザーグループとして追加します。

この連載では、Active DirectoryにHRおよびREWという組織グループ(OU)が存在し、それぞれにユーザーが位置していることを前提として作業を進めます。お手元の検証用Active Directoryの状態に合わせ、適宜読み替えてください。

Workspace ONE UEMコンソール トップページに戻ります。[アカウント] > [ユーザーグループ] > [リスト表示] を選択します。[追加] > [ユーザーグループを追加] を選択します。

タイプ: ディレクトリ
外部タイプ: 組織ユニット
テキスト検索: hr (ここでは既存のActive Directory OUを入力します)
[検索]をクリック

グループベースDNやグループ名がルックアップされるので[保存]をクリックします。

同様の手順でREWもユーザーグループとして追加します。

Active Directory Basic同期の確認

Workspace ONE Accessコンソールにログインします。[ID とアクセス管理] > [管理] > [ディレクトリ] を選択します。タイプ[他のディレクトリ]としてディレクトリが登録されていることを確認します。

ユーザーとグループを選択します。ディレクトリユーザーが追加されていること、またユーザー名をクリックしユーザー詳細などを確認します。

グループをクリックします。ユーザーグループが連携されていること、またユーザーグループ名をクリックし詳細などを確認します。

ここまでの作業で、Active DirectoryからWorkspace ONE UEMに追加されるディレクトリユーザーやユーザーグループを、Workspace ONE Accessにも連携しました。

Workspace ONE Accessでの認証ポリシーの構成

ディレクトリユーザーが、パスワードを用いてWorkspace ONE Accessにログインできるよう設定します。Workspace ONE UEMのウィザードでモバイルシングルサインオンを構成した際に、Workspace ONE Accessの認証ポリシーも自動構成されていますので、これを修正します。

Workspace ONE Accessコンソールにログインします。[IDとアクセス管理] > [セットアップ] > [VMware Workspace ONE UEM]を選択します。下方にスクロールし[Workspace ONE UEMを介したユーザーパスワード認証]で[有効]を選択し、[保存]をクリックします。

[IDとアクセス管理] > [管理] > [Built-In]を選択します。

[認証方法]セクションの[Workspace ONE UEMでのパスワード]にチェックを入れ、[保存]をクリックします。

[IDとアクセス管理] > [管理] > [ポリシー]を選択します。

[default_access_policy_set]をクリックします。[ポリシーの編集]ウィンドウが表示されます。[編集]をクリックします。

[2 構成]をクリックします。[デバイス タイプ: Windows 10]左の[ALL RANGES]をクリックします。

[ポリシー ルールの編集]ウィンドウが表示されます。[先の方法が失敗するか適用できない場合、次を実行]でドロップダウンメニューから[Workspace ONE UEMでのパスワード]を選択します。[保存]をクリックします。

[ポリシーの編集]ウィンドウに戻ります。[次へ]をクリックします。[保存]をクリックします。[3 サマリ]が表示されます。[保存]をクリックします。

今回の作業ではActive DirectoryのドメインユーザーをWorkspace ONE UEMのディレクトリユーザーとして追加しました。またActive Directoryの組織ユニット(OU)をWorkspace ONE UEMのユーザーグループとして追加しました。そしてWorkspace ONE UEMのディレクトリユーザーやユーザーグループをWorkspace ONE Accessに連携しました。

次回は、Workspace ONE UEMの特徴のひとつである階層構造を用いた管理を構成します。

The post Windows 10モダンマネジメントガイド 第3回 Active DirectoryユーザーをWorkspace ONE UEM/Accessへ連携 appeared first on VMware Japan Blog.

はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回は「触りながら学ぶ  vSphere with Tanzu」シリーズの第二回として vSphere Pod を操作しながら機能説明します。

vSphere Pod は一言で言ってしまうと VMware vSphere を構成する ESXi ホスト上で直接 Kubernetes （K8s）のワークロードを実行する技術です。おそらく多くの Kubernetes 実行環境は本シリーズの第一回で説明した「Tanzu Kubernetes Cluster（TKC）」と同じように「仮想マシンとして K8s のノード群をたちあげてクラスタを構築し、そのうえでコンテナを動かす」という構成かと思います。つまり、仮想マシンとコンテナという2階建ての構成になっているということです。一方、vSphere Pod はコンテナ用途に最適化された超軽量仮想マシンのうえでワークロード（Pod）を直接実行するという VMware ならではのテクノロジーです。

上記の図にあるように「Pod が ESXi 上で仮想マシンとして直接実行される」形態をとっています。言い方を変えると普通の K8s のように「ワーカーノード上に複数の Pod が共存する」という実行形式をとりません。そのため、Podレベルのパフォーマンスやアイソレーションに優れているという特徴があります。また、非常に小さいアプリケーションを動かすのに必要なリソースがTKC（冗長性を持ったマスターとワーカーノードを展開）に比べると小さいという特徴もあります。

ただし、注意が必要なのは「vSphere Pod が提供する K8s の機能が豊富ではない」という点です。たとえばHelmやIstioなどはvSphere Pod では利用できません。そういった背景がありますので、「vSphere with Tanzu で利用する K8s クラスタは、デフォルトでは一般的な K8s クラスタである TKC を利用する」とご認識ください。一般的な K8s アプリケーションが vSphere Pod では動作しない可能性があります。vSphere Pod の利用を検討する状況は、後ほど紹介する利用が適した場面とお考えください。

vSphere Pod の概念と使い所

vSphere Pod はスーパーバイザーネームスペース上に一般的な K8s の Pod リソースと同様に展開されます。実際にはDeployment や Service リソースなどとともに利用されるでしょうが、その使い方は YAML で定義して kubectl apply コマンドで適用するという標準的な使い方です。また、ネームスペースレベルでどれだけのリソースが使えて、誰がアクセスできるか決めれるのも K8s らしい使い方です。このように、vSphere Pod がワークロードをどのように動かすかということは特殊であるものの、ユーザーとしての使い方は普通の K8s と大差ありません。このあたりは実際に機器を操作するなかで体感していただければと思います。

TKCは操作体系だけでなく内部構成も一般的な K8s ですので、ほとんどのユースケースに合致します。一方で、vSphere Pod は使うべき場面が限定的です。2020年12月時点では推奨される利用場面は以下が求められる場合です。詳しくはドキュメントを参照ください。

• TKCのノード(マスター/ワーカー)が使用するCPUやメモリを削減したい。ESXi上で直接K8s Podを動作させるので、TKCのK8sノードとなる仮想マシン自体にリソースを使われません
• Podレベルでの独立性が必要な場合。1つのPodに問題が起きても仮想マシンレベルで独立しているため、他のポッドに影響がありません
• 1つのポッドで高いパフォーマンスが求められる場合。通常のK8sのポッドに比べて vSphere Pod は低いレイヤで動作します。マシンパワーや内部ネットワークのオーバーヘッドを減らせます。低遅延が求められたりモンスターPod（超巨大なPod）のような使い方をしたい場合です
• Podを従来の仮想マシンのように監視したい場合。vCenterで直接監視できます

vSphere Podには上記のような強みがある一方で、VMware の独自色が強いことに起因する弱点もあります。一番大きなものとしては、シンプルな使い方（サービスとデプロイメント及びネットワークとストレージの利用など）以外では機能的な制約によりワークロードを実行できない可能性が標準的な K8s である TKC に比べると高いことです。たとえばIstioなどは利用できません。また、vSphere流の監視ができる一方で、K8s流のモニタリングは難しくなります。その次にTKCと異なり、様々な利用者が同じスーパーバイザークラスター上でワークロードを展開するため、1つのK8sクラスタが管理するワークロードが多くなりがちという問題点もあります。TKCはクラスタレベルで完全にワークロードを分離できますが、vSphere Podはそれができません。繰り返しますが、2020年12月時点では「TKGS上で利用する K8s クラスタのデフォルトは TKC とし、vSphere Pod はそれが必要な場面以外では利用しない」という運用をおすすめします。なお、vSphere Podは今後も機能拡張していく予定ですので、将来的にはその用途が増えることが予想されます。

vSphere Pod の展開

ここからは実際に弊社が提供するラボ環境で vSphere Pod を利用してもらうことで、その機能を実体験していただきたいと思います。以下のシナリオで進めていきます。

1. VMware の HOL（Hands On Lab）のサイトにアクセスする
2. vSphere with Tanzu のラボを開始する
3. vSphere Pod のモジュール3（演習）に進む
4. vSphere Client 上でスーパーバイザークラスターの構成を確認する
5. kubectlコマンドでスーパーバイザークラスターに接続する
6. vSphere Pod のワークロード（ウェブアプリ）を展開
7. 展開したアプリにブラウザでアクセス
8. vSphere Client 上で vSphere Pod の VM（Pod, コンテナ用）を確認

まず、上記ステップの1から3ですが、これは前回の記事に書いた HOL へのアクセス法を参照してください。

触りながら学ぶ vSphere with Tanzu 第1回: Tanzu Kubernetes Cluster

モジュール3にある「LOG IN TO VCENTER」を参照して、vSphere Client にログインします。そして、メニューの「Hosts and Clusters（おそらく初期画面がこれ）」から Namespaces（スーパーバイザーネームスペース一覧）および demo-app-01（スーパーバイザーネームスペースの1つ）を開きます。そうすると TKC である tkg-cluster-01 の下に3つの hello-kubernetes… という VM のようなものが見えると思いますが、これがvSphere Podです。

次に自分で vSphere Pod を展開します。そのためには、まずモジュール3の「LOGIN TO SUPERVISOR CLUSTER」に従って、kubectl コマンドでスーパーバイザークラスターにログインをおこないます。このコマンドの解説はシリーズ第一回で説明していますが、vSphere with Tanzu のIPを指定して、ユーザー名を指定してログインします。ログインすると Kubernetes のコンテキスト（複数のK8s環境を使い分けるための標準的な仕組み）が得られるので、スーパーバイザーコンテキストを指定してスーパーバイザークラスタを操作できる状態にします。

上記の例では接続先のスーパーバイザークラスターの IP は 192.168.124.1 であり、接続ユーザーは administrator@corp.local です。そうすると、ユーザーが属するネームスペースである「demo-app-01」のコンテキストが得られました。そして、そのコンテキストに変更しています。

次に自分のアプリケーションを vSphere Podとして展開します。前回の復習も兼ねて説明すると「TKC のコンテキストで kubectl を使ってポッドを展開すると、TKC 上にポッドが展開される」「スーパーバイザーのネームスペースでポッドを展開すると、vSphere Pod がそのスーパーバイザーネームスペース上に展開される」という動きをします。サンプルアプリのマニュフェストが「~/labs/guestbook」にあるので、それを kubectl apply コマンドで展開してみます。

kubectl get pods コマンドや kubectl get svc コマンドの結果から、kubectl apply コマンドにより Pod（Deployment）と Service のリソースが展開されたことが確認できます。Pod が起動するまでに少し時間がかかっていますが、これはポッドの初回利用イメージを取得するダウンロード時間などが含まれるためです。サービス確認コマンドで確認しているサービスのタイプ:ロードバランザーとして公開された IP:192.168.124.3 （みなさまの環境では違うIPの可能性が高いです）にブラウザでアクセスすると、さきほど apply によりデプロイしたウェブサービスが動作していることが確認できます。

このアプリケーションを構成する Pod（コンテナ）は  vSphere Pod （vSphereの超軽量仮想マシン）として展開されているので、それを vSphere Client で確認してみます。今回利用したスーパーバイザークラスターの「demo-app-01」というネームスペースに着目してください。

先ほど確認した時に存在しなかった「frontend」「redis-master」「redis-slave」という3つの vSphere Pod が展開されていることが確認できました。これらは先ほど apply したマニュフェスト内で定義されています。

最後に展開したアプリケーションを通常の K8s のリソースのように削除をおこないます。kubectl delete でマニュフェストを指定してリソース削除をすると、CLI のレスポンスとしてリソースが削除されたことが確認でき、それに加えて vSphere Client 上からも vSphere Pod が削除されていることが確認できます。

以上で本記事の vSphere Pod の基本的な機能紹介を終えたいと思います。第1,2回は開発者目線の操作を中心に説明してきましたが、第3回では運用者側の視点で vSphere with Tanzu の管理と操作について紹介したいと思います。ご拝読ありがとうございました。

The post 触りながら学ぶ vSphere with Tanzu 第2回: vSphere Pod appeared first on VMware Japan Blog.

はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理、ゼロトラスト セキュリティを実現する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業ではVMware Workspace ONE UEMの特徴のひとつである階層構造を用いた管理を構成しました。

今回の作業ではVMware Workspace ONE Intelligent Hubを用いてWindows 10をWorkspace ONE UEMに加入します。次にWindows デスクトップ プロファイルを追加し、BitLocker、Windows Defender、Windows Update、制限などの様々な構成をWindows 10へ配信します。

Windows 10の加入

Workspace ONE Intelligent Hubを用いてWindows 10をWorkspace ONE UEMに加入します。詳細は以下のドキュメントを参照ください。

VMware Workspace ONE Intelligent Hub を使用して加入させる
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/Windows_Desktop_Device_Management/GUID-AWT-ENROLL-AGENTCONFIGWD.html

Intelligent Hub入手とインストール

Windows 10にドメインユーザーjpnawafw¥hr01でログインします。

jpnawafw¥hr01はログインしたWindows 10の管理者権限を有しているものとします。

Windows 10のウェブブラウザでhttps://getwsone.com/ にアクセスします。[Download Hub for Windows 10]をクリックしIntelligent Hubインストーラーをダウンロードします。https://getwsone.com/ はプラットフォームを問わず同一のURLでアクセスすることができます。iOSやAndroid, macOSなど、アクセスするプラットフォームに応じた最適なバージョンのIntelligent Hubをダウンロードすることができます。

エクスプローラーでダウンロードフォルダーを開きます。インストーラー AirWatchAgent.msiをダブルクリックして実行します。ウィザードに従いインストールを完了します。

Windows 10の加入

Intelligent Hubを用いてWindows 10をWorkspace ONE UEMに加入します。加入に用いる資格情報はActive Directoryのユーザー名とパスワードであるため、エンドユーザーが加入作業を行う際にも戸惑うことなく作業をスムースに行えます。加入時のURLはcn1109.awmdm.comではなくds1109.awmdm.comである点に留意ください。

Workspace ONE Accessにリダイレクトされます。ドメインの選択をSystem Domainからディレクトリ名に切り替えます。[この設定を保存]にチェックを入れ[次へ]をクリックします。

ユーザー名およびパスワードを入力します。

ウィザードに従い加入作業を続行します。加入が完了します。

前回の作業で構成した[グループID割り当てモード]の構成により、[HR] OU所属ユーザーの加入デバイスはサブ組織グループafw-hrに配置されていることを確認します。

画面上部で[組織グループ] > [afw-hr]を選択します。先程加入したWindows 10がこのサブ組織グループに配置され、デバイス一覧に表示されることを確認します。

画面上部[組織グループ] > [afw-rew]を選択します。デバイス一覧になにも表示されないことを確認します。デバイスはサブ組織グループafw-hrに配置されているためです。

Windows デスクトップ プロファイル

プロファイルには、デバイスに適用する設定、構成、および制限などが含まれています。プロファイルあたり単一のペイロードを構成することを推奨します。Windowsデスクトッププロファイルは、ユーザーまたはデバイスのいずれかのレベルに適用されます。
プロファイルは順守ポリシーと組み合わせて、企業のルールと手順を実施するのに役立つ設定やルールと考えることができます。

Windows 用の Workspace ONE UEM プロファイル
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/Windows_Desktop_Device_Management/GUID-AWT-PROFILE-OVERVIEWWD.html

Windows デスクトップ プロファイルの追加

Windows デスクトップ プロファイルを追加し、加入するデバイスに自動的に配信されるよう構成します。

Workspace ONE UEMコンソール トップページを表示します。画面上部[組織グループ] > [jpnawafw]を選択します。[追加] > [プロファイル] > [Windows] > [Windowsデスクトップ] > [デバイスプロファイル]を選択します。

全般ペイロード

[暗号化] > [構成]をクリックします。

暗号化ペイロード

[保存して公開]をクリックします。

[公開]をクリックします。

プロファイルは[全般]ペイロード(必須)および各ペイロード(=構成情報)を含むことができます。プロファイルには複数のペイロードを含めることができますが、なるべく1プロファイルにつき[全般]および1つのペイロードだけを含めるよう構成することを推奨します。

[デバイス] > [プロファイルとリソース] > [プロファイル]を選択します。Win-BitLockerプロファイルが追加されていることを確認します。

加入済みWindows 10ではWin-BitLockerプロファイルが自動インストールされ、BitLocker暗号化が始まります。プロファイルでは[システムが常に暗号化されたままにする]を有効にしているため、プロファイル削除や加入解除後もBitLocker暗号化は有効なままです。

デバイスは既定で6時間ごとに自身のデバイス情報(デバイスサンプルと呼びます)をUEMコンソールに送信します。

順守ポリシーエンジンは5分間隔で順守状態をチェックしますが、この時点ではまだWindows 10からデバイスサンプルが届いていないため、コンソールでは引き続き[BitLocker 保護: 進行中]や[デバイスは侵害されています][順守違反]等と表示されます。

コマンド[クエリ]を実行すると、該当デバイスに対しデバイスサンプルを要求することができます。[その他] > [トラブルシューティング] > [コマンド] を確認し、キュー済みや保留中のコマンドが無くなればデバイスサンプルの要求が完了しています。

5分ほど待ちブラウザをリロードすると順守違反が改善され[BitLocker 保護:オン]となっていることが確認できます。またリカバリキーも収集されているため、エンドユーザーデバイスでリカバリキーが必要になった際にもすぐに対応することができます。

[デバイスは侵害されています]表示は該当デバイスを再起動し、少し待つことで解消します。既定ではデバイス正常性構成証明で[起動時のBitLocker状態が無効化済み]をチェックしているためです。[その他] > [デバイス正常性構成証明]で確認することができます。

デバイス正常性構成証明

[グループと設定] > [構成] > [Windows正常性構成証明]で、どの項目をチェックするかカスタマイズすることができます。

正常性構成証明による侵害デバイスの検出
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/Windows_Desktop_Device_Management/GUID-AWT-HEALTHATTESTATION.html

アンチウィルスプロファイルの追加

アンチウィルスプロファイルを追加し、加入デバイスに自動的に配信されるよう構成します。通常であればグループポリシーオブジェクト(GPO)でのみ管理可能な詳細項目も、Active Directoryドメイン参加の有無を問わずリモート設定・管理することができます。

画面上部[組織グループ]> [jpnawafw] を選択します。

[追加] > [プロファイル] > [Windows] > [Windowsデスクトップ] > [デバイスプロファイル]を選択します。

全般ペイロード

[アンチウィルス] > [構成]をクリックします。

アンチウィルスペイロード

[保存して公開]をクリックします。

[公開]をクリックします。

[デバイス] > [プロファイルとリソース] > [プロファイル]を選択します。アンチウィルスプロファイルが追加されていることを確認します。

Windows更新プログラムプロファイルの追加

Windows更新プログラムを追加し、デバイスのWindows Update設定をコントロールします。

画面上部[組織グループ]> [jpnawafw] を選択します。[追加] > [プロファイル] > [Windows] > [Windowsデスクトップ] > [デバイスプロファイル]を選択します。

全般ペイロード

[Windows更新プログラム] > [構成]をクリックします。

Windows更新プログラムペイロード

[保存して公開]をクリックします。[公開]をクリックします。

[デバイス] > [プロファイルとリソース] > [プロファイル]を選択します。Windows更新プログラムプロファイルが追加されていることを確認します。

Windows 10で[スタート] > [設定] > [更新とセキュリティ]を選択します。[一部の設定は組織によって管理されています]が表示され、Windows更新プログラムプロファイルによりWindows Update設定が管理されていることが確認できます。

Workspace ONE UEMでは、機能更新プログラムや品質更新プログラム適用タイミングの異なる[Windows更新プログラムプロファイル]を複数作成し、スマートグループを用いてグルーピングしたWindows 10デバイスに対し適用することで、企業に適したWindows Update展開リングを構成することが可能です。クラウドから管理するため、オンプレミスネットワークに依存する構成管理ツールの必要がなく、それらに接続するためのデバイスVPNも不要です。

制限プロファイルの追加

制限プロファイルを追加し、Windows 10の望ましくない機能を制限します。

画面上部[組織グループ]> [jpnawafw] を選択します。[追加] > [プロファイル] > [Windows] > [Windowsデスクトップ] > [デバイスプロファイル]を選択します。

全般ペイロード

[Windows更新プログラム] > [構成]をクリックします。

制限ペイロード

[保存して公開]をクリックします。[公開]をクリックします。

[デバイス] > [プロファイルとリソース] > [プロファイル]を選択します。制限プロファイルが追加されていることを確認します。

Windows 10で[スタート] > [設定] > [アカウント] > [職場または学校にアクセスする]を選択します。[Workspace ONE UEMに接続済み]の[切断]をクリックすると制限プロファイルにより、ユーザー操作のMDM加入解除がブロックされていることが確認できます。

今回の作業ではWorkspace ONE Intelligent Hubを用いてWindows 10をWorkspace ONE UEMに加入しました。またWindows デスクトップ プロファイルを追加し、BitLocker、Windows Defender、Windows Update、制限などの様々な構成をWindows 10へ配信しました。

次回は順守ポリシーを構成し、デバイスの状態に応じたアクションの自動化を設定します。

The post Windows 10モダンマネジメントガイド 第5回 Windows 10の加入とプロファイル配信 appeared first on VMware Japan Blog.

まず大事なご報告です。2020年12月1日より、AVS を Azure 東日本リージョンでもご利用いただけるようになりました！
2020年5月のプレビュー発表以降、”いつから日本で使えるのか？”というお問い合わせを数多くいただいてきましたが、大変お待たせいたしました。これから本 Blog の場をお借りして、AVS に関する様々な情報をお届けできれば幸いです。

■ Azure VMware Solution とは？

Azure VMware Solution を一言で言うと、マイクロソフトが提供する VMware プライベートクラウド (Software-Defined Data Center) です。少し名称が長いので、頭文字をとって AVS (エーブイエス) と呼ぶことが多いです。

サービスの詳細は今後の記事で順次解説していきますが、初回となる今回は主なコンセプトを3つご紹介します。

AVS は、開発、運用、販売、サポートいずれにおいても Microsoft が一気通貫で対応するサービスです。
Azure 上で提供される他のサービス同様、たとえば障害対応サポートにおいても、マイクロソフトがお客様に対する単一の窓口として機能します。そのため、何か問題が発生したときにありがちな “どこに問い合わせればよいのか？”、”ベンダー間で回答がたらい回しで…”という心配がいりません。

もちろん現実的には、VMware 製品の技術固有の仕様に踏み込んだ障害対応や解析が必要になる場合も考えられます。その場合も Microsoft と VMware のサポートエンジニアが連携して問題対応にあたり、マイクロソフトとしてお客様に回答します。

AVS は、VMware が提供する「VMware Cloud Foundation (VCF)」 に基づいて、Microsoft と VMware が共同開発を行っています。
VCF は “ハイブリッドクラウド” を基本コンセプトとしたアーキテクチャーであり、現在オンプレミスでご利用中のプライベートクラウドと最大限の互換性を確保できるように設計されています。

たとえば AVS では、VMware が提供する VMware HCX を標準提供しています。HCX vMotion によるオンプレ ⇔ AVS 間での仮想マシンの無停止移動や、HCX L2 延伸機能を用いたセグメント延伸（＝ IP アドレスや MAC アドレスさえ変更しない仮想マシンの移行）が可能です。

これら移行は片道切符ではなく、AVS からオンプレミス側に仮想マシンを戻すことも可能です。
そのため、データセンターの縮小・廃止などを目的としたクラウド移行のシナリオはもちろん、たとえばビジネスの繁忙期でオンプレミス側リソースが不足するときだけ AVS を立ち上げて、コストを最適化しつつ必要なキャパシティをオンデマンドで確保するといった使い方もできます。
（料金体系については別の回に改めて触れますが、AVSは１時間単位の従量課金を採用しています）

少し観点が変わりますが、AVS では Azure ハイブリッド特典というライセンス特典も適用できます。オンプレミス側で所定のライセンスをお持ちのお客様は、新たにライセンスを調達することなく、AVS 上で Windows Server や SQL Server を稼働できます。
また Microsoft 365 Apps for enterprise （旧称 Office 365 ProPlus） や Windows 10 ももちろん利用できますので、たとえば VDI のような用途でも AVS をご活用いただけます。
（ライセンス関連の特典もよくご質問いただく事項ですので、別の回でより深く解説します）

3. Azure ネイティブサービスとの高い親和性

AVS は、グローバルパブリッククラウドである Microsoft Azure 上のサービスの一つとして提供されます。Azure では現在 200 を超えるサービスが提供されており、どれか一つを単独でご利用することもできますが、複数のサービスを組み合わせていただくことで、クラウドらしい柔軟性や拡張性、俊敏性を享受できます。

組み合わせ方法は無限大ですが、AVS とほかのAzureサービスの典型的な統合例をご紹介します。

• Microsoft Azure Backup Server (MABS) を用いて AVS 上の仮想マシンを簡単バックアップ。安価なクラウドストレージ (BLOB) にアーカイブを保管できるためコストも最適化。
• レイヤー 7 Web トラフィック ロード バランサーである Azure Application Gateway を用いた、柔軟性とスケーラビリティの高い負荷分散の実現。
• Azure セキュリティ関連サービスを用いたセキュリティの向上。ワークロード全体の高度な脅威保護を提供する Azure Security Center、統合ログ管理を行う Log Analytics、クラウドネイティブな SIEM + SOAR を実現する Azure Sentinel などさまざまなセキュリティ関連サービスを提供しており、AVS 上の仮想マシンもこれらの保護対象に含めることが可能。

■ もっと知りたいという方は？

本記事では、ついに日本でも提供が始まった Azure VMware Solution の基本コンセプトをお伝えしました。

今後もさまざまな視点から最新情報や技術解説を行う予定ですが、「今すぐ AVS の概要・全体像を知りたい！」 という方がいましたら、過去に実施した AVS ウェビナーの録画版をぜひご視聴ください。もちろん弊社担当営業にお問い合わせいただければ、より詳しいご紹介も可能です。

The post Azure VMware Solution の Azure 東日本リージョン提供開始！ appeared first on VMware Japan Blog.

はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理、ゼロトラスト セキュリティを実現する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業ではWindows 10をVMware Workspace ONE UEMに加入しました。またBitLocker、Windows Defender、Windows Update、制限などの様々な構成をWindows 10へ配信しました。

今回の作業では順守ポリシーを構成し、エンドユーザーへの通知などを自動化します。また無効化されたファイアウォールの復旧アクションを自動化する順守プロファイルを作成、適用します。

順守ポリシー

順守ポリシーにより、管理者が定義したポリシーをすべてのデバイスが順守していることを保証します。ポリシーにはアンチウィルスやファイアウォールの状態、デバイス暗号化状態などがあります。
デバイスが非順守状態であると判断されると、順守違反を正すようユーザーにメッセージを送信します。それでも非順守状態が是正されない場合の対応措置を段階的に設定し、自動で実行することもできます。

順守ポリシー
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/UEM_Managing_Devices/GUID-AWT-COMPLIANCEPOLICIESOVERVIEW.html

順守ポリシーの作成

この作業では、デバイスが順守すべき基本的なポリシーを作成します。デバイスのWindows Defender，BitLocker，Windows Defenderファイアウォールの状態の確認、およびWindows 10バージョン1909以上であることをチェックし、いずれかの状態が不良であれば順守違反となるよう構成します。

また自動化アクションでは順守違反デバイスのユーザーに対してEメールで通知を送り、改善されなければ3日後にVPNプロファイルなどをブロック、5日後には企業リソースに一切アクセスできないようワイプを実行するよう構成します。

Workspace ONE UEMコンソール トップページを表示します。

画面上部[組織グループ] > [jpnawafw] を選択します。[追加] > [順守ポリシー]を選択します。

Windowsを選択します。Windowsデスクトップを選択します。

1. ルール を構成します。

• 任意に合致する
• ウィルス対策ソフト: が次に該当しない: 良好
• 暗号化: 暗号化されていない
• ファイアウォール状態: が次に該当しない: 良好
• OSバージョン: 次の値以下: 10.0.18362 (※バージョン1903以下)

[次へ]をクリックします。

2. アクション を構成します。

[さらに強い対応措置を追加]をクリックします。

• 通知: Eメールをユーザーに送信

が追加されます。

[さらに強い対応措置を追加]をクリックし、次のように構成します。

• 次の日数後: 3日
• プロファイル: すべてのプロファイルをブロック

[さらに強い対応措置を追加]をクリックし、次のように構成します。

• 次の日数後: 5日
• コマンド: 企業情報ワイプ

[次へ]をクリックします。

3. 割り当て を構成します。

• スマート グループ: All Corporate Dedicated Devices

[次へ]をクリックします。

4. 概要を確認します。ポリシー名や説明を入力します。[完了してアクティブ化]をクリックします。

[デバイス] > [順守ポリシー] > [リスト表示]を選択します。順守ポリシーが追加されていることを確認します。

Workspace ONE UEMコンソール トップページに戻ります。

[デバイス] > [リスト表示] > 該当デバイスを選択します。加入済みのWindows 10がセキュリティポリシーを満たしている際には、順守違反のない旨の表示となります。

順守ポリシーで修復を自動化

この作業では、自動修復のための順守ポリシーおよび順守プロファイルを構成します。Windows 10デバイスのWindows Defenderファイアウォールの状態をチェックし、エンドユーザーによる無効化=状態不良であれば順守プロファイルをインストールすることで、Windows Defenderファイアウォールを有効化状態に復旧します。

順守プロファイルの作成

Workspace ONE UEMコンソール トップページを表示します。

画面上部[組織グループ] > [jpnawafw] を選択します。[追加] > [プロファイル] > [Windows] > [Windowsデスクトップ] > [デバイスプロファイル]を選択します。

全般ペイロード

ファイアウォールペイロード
Domain / Private / Public 各項目を以下のように設定

[保存して公開]をクリックします。

順守ポリシーの追加

Workspace ONE UEM コンソール トップページを表示します。

画面上部[組織グループ] > [jpnawafw] を選択します。[追加] > [順守ポリシー]を選択します。Windows を選択します。Windowsデスクトップを選択します。

1. ルール を構成します。

ファイアウォール状態: が次に該当しない: 良好

[次へ]をクリックします。

2. アクション を構成します。

プロファイル: 順守プロファイルをインストールする: Win-Firewall

[次へ]をクリックします。

3. 割り当て を構成します。

スマート グループ: All Corporate Dedicated Devices

[次へ]をクリックします。

4. 概要を確認します。[完了してアクティブ化]をクリックします。

[デバイス] > [順守ポリシー] > [リスト表示]を選択します。順守ポリシーが追加されていることを確認します。

Windows 10での動作確認

Windows 10で[ファイアウォールの状態の確認]を開きます。[Windows Defenderファイアウォールの有効化または無効化]をクリックします。

ドメイン/プライベート/パブリック各範囲の[Windows Defenderファイアウォールを無効化します (推奨されません)]を選択し、[OK]をクリックします。

Workspace ONE UEMコンソール トップページに戻ります。

[デバイス] > [リスト表示] > [該当デバイス]を選択します。コマンド[クエリ]をクリックし実行します。数分待ってブラウザをリロードすると順守違反状態に変化します。

5分ほど待つと順守ポリシーに従いアクションが実行されます。[Win-Firewall]順守プロファイルがインストールされ、Windows Defenderファイアウォールが有効化状態に戻ります。

今回の作業では順守ポリシーを構成しました。また順守プロファイルを作成し、無効化されたファイアウォールの復旧アクションを自動化しました。

次回はベースラインを構成します。

The post Windows 10モダンマネジメントガイド 第6回 順守ポリシーの構成 appeared first on VMware Japan Blog.

はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理、ゼロトラスト セキュリティを実現する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業では順守ポリシーを構成しました。また順守プロファイルを作成し、無効化されたファイアウォールの復旧アクションを自動化しました。

概要

今回の作業ではVMware Workspace ONE UEMコンソールでベースラインを構成し、カスタマイズでレジストリエディター起動禁止を追加します。ベースラインをWindows 10へ配信し、ベースラインが適用されていることを確認します。

ベースライン

ベースラインは業界推奨の設定と構成を使用して、デバイスの設定を業界のベストプラクティスに準拠させ、簡単に広範囲のWindows 10デバイスのハードニングを行うことができます。Workspace ONE UEM 管理下の Windows 10 に対し、Active Directory参加の有無や会社ネットワーク内外などの条件を問わず適用することができ、モダンマネジメント環境においてデバイスをセキュアに保つことができます。

ベースラインの使用
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/Windows_Desktop_Device_Management/GUID-35F5B92C-9331-48B6-B9D1-69DB682368B3.html

ベースラインの構成

Workspace ONE UEMコンソール トップページを表示します。画面上部[組織グループ]> [jpnawafw]を選択します。

[デバイス] > [プロファイルとリソース] > [ベースライン]を選択します。[新規]をクリックします。

ベースライン名と説明を入力し、次へ をクリックします。

[ベースラインの選択] 画面では[Windows 10 Security Baseline – バージョン1909]を選択します。

[カスタマイズ] 画面では、テンプレートに含まれるセキュリティ項目を確認します。設定変更は行わず[次へ]をクリックします。

[ポリシーを追加] 画面で、検索欄に“registry edit”と入力します。補完表示される[Prevent access to registry editing tools]をクリックします。

項目を以下のように調整します。

次へ をクリックします。

[概要]が表示されます。[保存して割り当て]をクリックします。

[ベースラインの割り当て]画面が表示されます。スマートグループの検索欄に“All”と入力します。補完表示される[All Corporate Dedicated Devices]を選択します。

[公開]をクリックします。

Windows 10でベースライン適用の確認

Windows 10デバイスでは、VMware Workspace ONE Intelligent Hubからの通知が表示されます。Windows 10デバイスを再起動します。ベースラインにWindows 10の再起動を必要とする項目が含まれるためです。

Windows 10デバイスにログインします。Windows 10デバイスにUSBドライブを挿入すると以下のような表示が現れます。今回選択したベースラインテンプレートには「BitLockerで保護されていないリムーバブルドライブへの書き込みアクセスを拒否する」が含まれています。ベースラインが正しく適用されていることが分かります。

レジストリエディターの起動を試みます。ベースラインに追加したポリシーが有効なため、レジストリエディターが起動できないことを確認します。

Workspace ONE UEMコンソールでベースライン適用の確認

Workspace ONE UEMコンソールで[デバイス] > [プロファイルとリソース] > [ベースライン]を選択します。ベースライン名をクリックします。

インストール状態や順守状態、インストールされたデバイスフレンドリ名などを確認します。

本連載では詳細には触れませんが、Microsoft Security Compliance Toolkitに含まれるLGPO.exeおよびPolicyAnalyzer.exeを用いて、ベースライン適用前と適用後の設定を比較するのも良いでしょう。

今回の作業ではWorkspace ONE UEMコンソールでベースラインを構成し、カスタマイズでレジストリエディター起動禁止を追加しました。ベースラインをWindows 10へ配信し、ベースラインが適用されていることを確認しました。

次回はWin32アプリケーション配信を構成します。

The post Windows 10モダンマネジメントガイド 第7回 ベースラインの構成 appeared first on VMware Japan Blog.

The post 保護中: [TAM Blog] TAM Data Manager（TDM）取得手順のご案内 appeared first on VMware Japan Blog.

はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理、ゼロトラスト セキュリティを実現する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業ではベースラインを構成しWindows 10へ配信しました。

今回の作業ではWin32アプリケーションを簡単に企業アプリリポジトリから追加します。加入したデバイスに自動でインストールされるタイプ、ユーザー自身がHubアプリカタログから選択してインストールできるオンデマンド配信タイプを確認します。

Win32アプリ配信

この作業ではVMware Workspace ONE UEMコンソールにWin32アプリを追加します。この際、企業アプリリポジトリから選択して追加します。Google Chromeは自動配信、7-Zip Managerはオンデマンド配信となるよう構成します。

Win32 アプリケーションのソフトウェア配布
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/Software_Distribution/GUID-AWT-WIN32-SOFDIST-DSCRPTN.html

企業アプリケーション リポジトリからの Windows アプリケーションの追加
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/Software_Distribution/GUID-FB0F7A34-BF34-469B-9682-256CFEC9571B.html

Google Chromeを自動配信

Workspace ONE UEMコンソール トップページを表示します。画面上部[組織グループ]> [jpnawafw] を選択します。[アプリとブック]を選択します。

リスト表示が[社内]であることを確認し、[追加] > [企業アプリリポジトリから]を選択します。

[アプリケーションを追加]検索画面が表示されます。[1 リポジトリ]では検索場所に“chrome”と入力し[Enter]を押下します。[Chrome for Business 64-bit]を選択します。

[次へ]をクリックします。

[2 詳細]画面では[次へ]をクリックします。

[3 概要]画面では[保存]をクリックします。

[Chrome for Business 64-bit]が追加されたことを確認します。Chromeの[割り当て]をクリックします。

[Chrome for Business 64-bit – 割り当て]画面が表示されます。項目を以下のように調整します。

[作成]をクリックします。

[Chrome for Business 64-bit – 割り当て]画面に戻ります。[保存]をクリックします。

[Chrome for Business 64-bit – 割り当てデバイスプレビュー] 画面が表示されます。[公開]をクリックします。

Chromeの自動インストール確認

Windows 10デバイスでは、VMware Workspace ONE Intelligent Hubからの通知が表示されます。少し待つとGoogle Chromeが自動インストールされます。

7-Zip Managerをオンデマンド配信

Workspace ONE UEMコンソール トップページを表示します。画面上部[組織グループ]> [jpnawafw] を選択します。[アプリとブック]を選択します。リスト表示が[社内]であることを確認し、[追加] > [企業アプリリポジトリから]を選択します。

[アプリケーションを追加]検索画面が表示されます。[1 リポジトリ]では検索場所に“zip”と入力し[Enter]を押下します。[7-Zip (x64)]を選択します。[次へ]をクリックします。

[2 詳細]画面では[次へ]をクリックします。

[3 概要]画面では[保存]をクリックします。[7-Zip (x64)]が追加されたことを確認します。

追加された7-Zipの[割り当て]をクリックします。

[7-Zip (x64) – 割り当て]画面が表示されます。項目を以下のように調整します。

[作成]をクリックします。

[保存]をクリックします。[7-Zip (x64) – 割り当てデバイスプレビュー] 画面が表示されます。[公開]をクリックします。

7-Zip Managerのオンデマンドインストール

Windows 10デバイスでWorkspace ONE Intelligent Hubを起動します。リロードをクリックすると、アプリカタログ表示が更新され、Google Chromeと7-Zip Managerが表示されます。

7-Zip Managerをクリックし[インストール]をクリックします。少し待つと7-Zip Managerがオンデマンドインストールされます。

今回の作業ではWin32アプリケーションを簡単に企業アプリリポジトリから追加しました。Google Chromeを自動配信に、7-Zip Managerをオンデマンド配信に、それぞれ構成しました。

次回の作業ではSAML対応ウェブアプリケーションへのシングルサインオンを構成します。

The post Windows 10モダンマネジメントガイド 第8回 Win32 アプリ配信 appeared first on VMware Japan Blog.

はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理、ゼロトラスト セキュリティを実現する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業ではWin32アプリケーションを追加しWindows 10へ配信しました。

今回の作業ではSAML連携ウェブアプリケーションへのシングルサインオンを構成します。エンドユーザーはVMware Workspace ONE Intelligent Hubアプリカタログからウェブアプリをクリックするだけで、証明書認証によりユーザー名やパスワードを入力することなくアプリが利用できることを確認します。

SAML連携ウェブアプリケーションへのシングルサインオンを構成

今回の作業ではVMware Workspace ONE Accessに、SAML連携ウェブアプリケーションであるVMware Workspace ONE UEM セルフサービスポータルを追加します。

Workspace ONE Access での Web アプリケーションへのアクセスの提供
https://docs.vmware.com/jp/VMware-Workspace-ONE-Access/services/ws1-access-resources/GUID-57B66680-A118-47DD-B3A3-81EAD6D6CAA7.html

VMware Identity Manager Integrations Documentation
https://www.vmware.com/support/pubs/vidm_webapp_sso.html
※ VMware Identity ManagerはWorkspace ONE Accessの旧称です

Workspace ONE UEM セルフサービス ポータル
https://docs.vmware.com/jp/VMware-Workspace-ONE-UEM/services/UEM_ConsoleBasics/GUID-AWT-SELFSERVICEPORTALOVERVIEW.html

エンドユーザーはセルフサービスポータルにログインして、自身のデバイスに関する基本的な管理タスクの実行、問題の調査および解決を行うことができます。これによりヘルプデスク業務を低減し、サポート担当者の負荷を軽減できます。

エンドユーザーは通常、https://workspaceone_tenant_url/MyDevice にアクセスし、グループIDおよびユーザー名・パスワードを入力してセルフサービスポータルにログインします。Identity ProviderであるWorkspace ONE AccessとService Providerであるセルフサービスポータルとの間でSAMLフェデレーションを構成することで、エンドユーザーはセルフサービスポータルにシングルサインオンすることができるようになります。

(Identity Provider) Workspace ONE Accessにセルフサービスポータルを追加

Workspace ONE Access 管理コンソールにログインします。[カタログ] > [ウェブアプリケーション]を選択します。

[新規]をクリックします。[新規 SaaS アプリケーション]画面が表示されます。

[1 定義]では検索場所に“AirWatch”と入力し、表示される[AirWatch Mobile Device Management]を選択します。[名前]を[セルフサービスポータル]に変更します。

[次へ]をクリックします。

[2 構成]画面で下部にスクロールし、[アプリケーションパラメータ]項目に値を入力します。

[次へ]をクリックします。

[3 アクセスポリシー]画面では[次へ]をクリックします。

[4 サマリ]画面では[保存して割り当て]をクリックします。

[割り当て]画面では検索場所に“all”と入力し、表示される[All Users]を選択します。[選択されたユーザー/ユーザーグループ: ALL USERS]の[展開の種類]を[自動]に変更します。

[保存]をクリックします。

これでWorkspace ONE Accessにセルフサービスポータルが追加されました。

(Service Provider) セルフサービスポータルでSAML認証の有効化

Workspace ONE Access 管理コンソールにて、[カタログ] > [Webアプリケーション]を選択し、[設定]をクリックします。

[設定]画面で[SAMLメタデータ]をクリックします。[IDプロバイダ(IdP)メタデータ]をクリックし、表示されるxml形式データ(idp.xml)をダウンロード保存します。

Workspace ONE UEMコンソール トップページを表示します。

画面上部[組織グループ]> [jpnawafw] を選択します。[グループと設定] > [すべての設定] > [システム] > [エンタープライズ統合] > [ディレクトリサービス] を選択します。

下方にスクロールし、[認証にSAMLを使用]を有効化します。[以下のユーザーに対しSAML認証を有効化]では[セルフサービスポータル]にのみチェックが入るよう調整します。

[SAML 2.0]の[IDプロバイダの設定をインポート]で[アップロード]をクリックし、先に保存済みのidp.xmlをアップロードします。

下方にスクロールし、いったん[保存]をクリックします。

表示が更新され、[IDプロバイダのID]や[IDプロバイダ シングルサインオン用URL]などが表示されていることを確認します。

[応答バインドタイプ]を[POST]に変更します。
[認証応答セキュリティ]を[応答署名を検証]に変更します。

[保存]をクリックします。

右上の[X]をクリックして設定画面を閉じます。

シングルサインオンプロファイルの調整

第２回の作業で、ウィザードに従い[モバイルシングルサインオン]のセットアップを完了しました。ここでWindows 10用シングルサインオンプロファイルが作成されていますので、これを修正します。

Workspace ONE UEMコンソール トップページを表示します。画面上部[組織グループ]> [jpnawafw] を選択します。

[デバイス] > [プロファイルとリソース] > [プロファイル]を選択します。プロファイル名が[Windows_Sso_xxxx(数字)]となっているものを見つけ、鉛筆アイコンをクリックします。

シングルサインオンプロファイルが表示されます。[全般]ペイロードで[スマートグループ]を[All Corporate Dedicated Devices]に設定します。

[SCEP]ペイロードを選択します。右下の[バージョン追加]をクリックし、[証明書テンプレート]を[証明書(クラウド展開)]に変更します。

右下の[保存して公開]をクリックします。

[デバイス割り当て表示]が表示されます。[公開]をクリックします。

セルフサービスポータルへのシングルサインオン

シングルサインオンプロファイルにより証明書が配信されるまで数分待ってから、Windows 10デバイスでWorkspace ONE Intelligent Hubを起動します。リロードをクリックするとアプリカタログ表示が更新され、セルフサービスポータルが表示されます。

[セルフサービスポータル]をクリックします。既定のウェブブラウザが起動し、[認証用の証明書の選択]が表示されます。[OK]をクリックします。

セルフサービスポータルにシングルサインオンが完了します。

今回の作業ではSAML連携ウェブアプリケーションへのシングルサインオンを構成しました。エンドユーザーはIntelligent Hubアプリカタログからウェブアプリをクリックするだけで、証明書認証によりユーザー名やパスワードを入力することなくアプリが利用できることを確認しました。

次回はデバイスコンプライアンスを用いたSAML連携ウェブアプリケーションの利用を構成します。

The post Windows 10モダンマネジメントガイド 第9回 SAML連携ウェブアプリへのシングルサインオン appeared first on VMware Japan Blog.

VMware SD-WAN by VeloCloud は Microsoft Azure Virtual WAN と Microsoft 365 のネットワーク認証パートナーです

Microsoft Azure Virtual WAN （以下 Virtual WAN）は、Microsoft の IaaS 環境である Azure とユーザー拠点やデータセンター環境を柔軟に接続することができるネットワークハブとなるソリューションです。今回は、この Virtual WAN の導入を加速し、さらに 120% 活用する VMware SD-WAN by VeloCloud （以下 VMware SD-WAN）とのユースケースについてご紹介していきたいと思います。海を渡る構成をご検討のユーザーさまは必見です！

コンテンツ：
VMware SD-WAN と Azure Virtual WAN の接続で実現！Azure 接続を最適化するネットワークとは
Azure Virtual WAN & VMware SD-WAN 連携による高品質な国際拠点間接続の実現

VMware SD-WAN と Azure Virtual WAN の接続で実現！Azure 接続を最適化するネットワークとは

Microsoft Azure はクラウド上のサービスのため、Microsoft 365 などの SaaS サービスと同様に、ユーザー環境からクラウドまでの WAN 環境の構成に依存して、運用性やユーザー使用体感に大きな影響があります。

ユーザー環境から Microsoft Azure 環境への接続としては、拠点ごとに Virtual WAN との VPN にて接続する、Azure ExpressRoute によりユーザー専用回線として接続する、などの方法が考えられます。しかしこれらの接続方式では、運用・管理面やコスト面での課題が考えられ、クラウド導入のボトルネックとなる可能性もあります。

VMware SD-WAN は Virtual WAN の接続パートナー認定を取得しており、ユーザー環境と Azure をつなぐソリューションとして十分に検証済みであり、また非常に簡単にユーザー環境と Virtual WAN 接続を実現することができるソリューションです。以下では、より具体的な課題と解決策について考えてみたいと思います。

Virtual WAN では VPN による接続拠点数に応じた課金体系があるため、Azureへの接続拠点が多い場合はコスト増が懸念されます。また暗号化のみを行う VPN 接続では、ベストエフォート型のブロードバンドインターネット回線を活用するWAN環境を構築する場合、ユーザー環境からクラウドまでのアクセス区間における通信品質担保が難しくなります。（図1）

図1 企業ネットワークから Azure 環境への接続課題

VMware SD-WAN はこのような課題を包括的に解決することが可能です。

VMware SD-WAN クラウドゲートウェイは Virtual WAN における外部ネットワークとの接続ポイントである Virtual Hub (vHub) との接続集約点となることが可能です。図2 の構成のように、VMware SD-WAN クラウドゲートウェイにて各拠点からのセキュアなアクセスを VMware SD-WAN クラウドゲートウェイで集約し、vHub への接続をシングルポイントとすることで、接続拠点数による Azure 側のコストを抑制できます。

また、WANの環境はインターネットブロードバンド回線を活用頂く場合においても、各拠点からクラウドまでをセキュアに且つ回線品質を改善することが可能な SD-WAN オーバーレイにより通信させることが可能です。

VMware SD-WAN の各拠点環境への展開も非常にシンプルな仕組みのため、企業ユーザーはこのような Microsoft Azure までのアクセス領域の構成を非常に簡単に、また短期間で実現することが可能となります。

図2 VMware SD-WAN クラウドゲートウェイを活用した Azure Virtual WAN への接続構成

VMware SD-WAN のクラウド接続に対する技術的な優位性については、こちらの記事も合わせてご参照ください。

Azure Virtual WAN & VMware SD-WAN 連携による高品質な国際拠点間接続の実現

グローバルに拠点を展開する企業では、各国の拠点間を接続するため、国際専用線を敷設するような場合があります。しかし、国際専用線接続のようなサービスは運用コストが非常に高くなることが多く見受けられます。一方でベストエフォート型のインターネット回線を使ってしまう場合、国内使用に比べ、更に回線の品質を担保することが困難となってきます。（図3）

図3 一般的な国際拠点間を結ぶ企業 WAN 構成の課題

このような国際拠点間接続の新たなアプローチとして、VMware SD-WAN & Virtual WAN の連携活用によるソリューションをご提供可能です。

Microsoftはビジネスレベルの可用性・セキュリティを兼ね備える高品質グローバルバックボーンを有し、これが高品質な SaaS/IaaS サービスの基盤となっています。大陸を跨ぐような拠点間接続を実現するにあたり、国際網にはこの Microsoft グローバルバックボーンを活用し、各国国内の WAN 接続には VMware SD-WAN をご利用頂くことで、以下図4 の構成のように国際拠点間接続を実現することが可能です。

図4 VMware SD-WAN と Azure Virtual WAN を活用した国際拠点間接続の構成

この構成では、各国のVMware SD-WAN 構成と Virtual WAN との接続が完了するだけで、国を跨いだ複数地域を高品質な Microsoft グローバルバックボーン経由で接続することができます。Azure のウェブポータルから設定するだけで Microsoft グローバルバックボーン経由の接続は構築可能なため、国際回線準備に時間を要することはありません。

VMware 社内 IT での本ソリューションの活用事例では、北米ーアジア間の接続をこの方式に置き換えることで、8割以上の運用コスト削減に成功したという報告されております。国際拠点間接続の構築リードタイムを大幅に短縮できることが見込めるだけでなく、運用コストの面でもメリットがでる場合が多いソリューションであると考えております。

まとめ

本稿では、Virtual WAN と VMware SD-WAN の連携ソリューションについてご紹介してまいりました。企業 WAN を Azure へ接続する際のソリューションとしてのみならず、国際専用線に代わり国際拠点間接続への活用も可能となります。当然、「つなぐ」のみならず、Microsoft Azure をご利用いただけるのが最大のメリットです！他にもまだまだ活用例が出てきそうな Virtual WAN と VMware SD-WAN の連携ソリューションですが、ユーザー様でも「こんな使い方はできないの？」などございましたら、ぜひ弊社までお気軽にお問い合わせください。

VMware SD-WAN とクラウドに関連するお話は別の記事でもご紹介しておりますので、合わせてご覧ください。

なぜ VMware SD-WAN by VeloCloud はクラウド時代の企業 WAN に最適なソリューションであるのか

VMware SD-WAN by VeloCloud でクラウド上に仮想拠点を建てる話

免責事項

• 本稿でご紹介の VMware SD-WAN by VeloCloud のソリューションは一部開発中のものも含まれております。今後詳細が変更となる可能性もございますことご了承ください。
• 本稿で記載の Microsoft ソリューション説明については、内容の完全性を担保するものではございません。Microsoft ソリューション詳細につきましては、全て Microsoft 社からの情報が優先されますこと、ご了承ください。

参考情報

VMwareのイベント情報

今後のオンラインセミナー実施予定などはこちらからご確認頂けます

VMware ハンズオンラボ

ハンズオンラボは、VMwareの最新の製品やソリューションを、様々なシナリオに沿って、オンデマンドで利用することができます。VMware SD-WAN 入門としては以下コースがございますのでご参照下さい。

• • HOL-2140-01-NET – VMware SD-WAN by VeloCloud – Getting Started
  • HOL-2140-91-NET – VMware SD-WAN by VeloCloud – Lightining Lab

VMware SD-WAN by VeloCloud の最新情報 (英語)

VMware SD-WAN の最新情報はこちらでご紹介しております。

ヴイエムウェア営業へご連絡を希望される場合は下記URLのフォームよりお問い合わせください。

https://www.vmware.com/jp/company/contact_sales.html

The post Microsoft Azure Virtual WAN が SD-WAN と実現する次世代企業ネットワークとは appeared first on VMware Japan Blog.

はじめに

この連載では、VMware Workspace ONEを用いてクラウドからWindows 10を管理、ゼロトラスト セキュリティを実現する「最新の管理(モダンマネジメント)」の体験をご紹介します。

前回の作業では今回の作業ではSAML連携ウェブアプリケーションへのシングルサインオンを構成しました。

今回の作業ではデバイス順守(デバイスコンプライアンス)を構成し、SAML連携ウェブアプリケーションの利用時にデバイスの順守状態をチェックします。デバイスが非順守状態の場合、SAML連携ウェブアプリの利用ができないことを確認します。

デバイスコンプライアンスの構成

今回の作業ではVMware Workspace ONE Accessで認証方法としてデバイス順守を有効化します。次にデバイス順守状態をチェックする新たなポリシーを作成し、セルフサービスポータルに適用します。最後にWindows 10を非順守状態とする順守ポリシーを構成し、セルフサービスポータルへアクセス拒否されることを確認します。

Enabling Compliance Checking for Workspace ONE UEM Managed Devices
https://docs.vmware.com/en/VMware-Workspace-ONE-Access/3.3/idm-administrator/GUID-EF834B6D-C3EC-48BA-B38D-1574F7E4B773.html

デバイス順守の有効化

Workspace ONE Access 管理コンソールにログインします。[IDとアクセス管理] > [セットアップ] > [VMware Workspace ONE UEM]を選択します。

下方にスクロールし、[コンプライアンスチェック]を有効化します。[保存]をクリックします。

[IDとアクセス管理] > [管理] > [認証方法] を選択します。[Workspace ONE UEMとのデバイス順守]が[有効]であることを確認します。

[IDとアクセス管理] > [管理] > [IDプロバイダ] を選択します。[Built-In]をクリックします。

[認証方法]の[Workspace ONE UEMとのデバイス順守]にチェックを入れます。下方にスクロールし[保存]をクリックします。

[IDとアクセス管理] > [管理] > [ポリシー] を選択します。[ポリシーを追加]をクリックします。

[1 定義]ではポリシー名および説明を入力します。[適用先]では[セルフサービスポータル]を選択します。

[次へ]をクリックします。

[2 構成]では[ポリシールールを追加]をクリックします。

以下のようにポリシールールを構成します。

[ユーザーは次を使用して認証することができます: 証明書 (クラウドデプロイ)]の右の⊕をクリックすると[および]が追加され、[Workspace ONE UEMとのデバイス順守]を選択することができます。

下方にスクロールし[高度なプロパティ]をクリックします。カスタムメッセージ欄に任意のメッセージを入力します。

(例)「Workspace ONEに加入しておらず管理されていない または デバイスが正しい状態にない(非順守状態)」

[保存]をクリックします。

[次へ]をクリックします。

[3 サマリ]では[保存]をクリックします。

留意点: 本番の運用環境では、セルフサービスポータルへのデバイスコンプライアンスポリシー適用は行いません。あくまで本演習での設定例とお考えください。

デバイスコンプライアンス動作確認

非順守状態のWindows 10でセルフサービスポータルの利用を試みます。

既存の順守ポリシーの無効化

Workspace ONE UEMコンソール トップページを表示します。画面上部[組織グループ]> [jpnawafw] を選択します。[デバイス] > [順守ポリシー] > [リスト表示] を選択します。

[セキュリティポリシー] 左の緑●をクリックし無効化します。
[ファイアウォール状態] 左の緑●をクリックし無効化します。

[状態]を[すべて]に変更し、既存の順守ポリシーが赤●となっていることを確認します。

一時的な順守ポリシーの作成

デバイスを[非順守]扱いにするための一時的な順守ポリシーを作成します。

画面上部[組織グループ]> [jpnawafw] を選択します。[追加] > [順守ポリシー]を選択します。Windowsを選択します。Windowsデスクトップを選択します。

[1. ルール] を構成します。

• OSバージョン: 次の値以下: 10.0.19042 (※バージョン20H2以下)

[次へ]をクリックします。

[2. アクション] は既定のまま変更せず[次へ]をクリックします。

[3. 割り当て] を構成します。

• スマート グループ: All Corporate Dedicated Devices

[次へ]をクリックします。

[4. 概要] は既定のまま変更せず[完了してアクティブ化]をクリックします。順守ポリシーが追加されていることを確認します。

[デバイス] > [リスト表示] を選択します。

加入済みのWindows 10が[非順守状態]となっていることを確認します。まだ[非順守状態]ではない場合、5分ほど待ってからブラウザをリロードします。

非順守状態のWindows 10でセルフサービスポータルを利用

Windows 10デバイスでVMware Workspace ONE Intelligent Hubを起動します。[セルフサービスポータル]をクリックします。

既定のウェブブラウザが起動しますが「アクセスは拒否されました」が表示され、セルフサービスポータルが利用できないこと、なぜアクセスが拒否されたか、エンドユーザーに分かりやすいエラーメッセージが表示されることを確認します。

順守ポリシーを元に戻す

デバイスを[非順守]扱いにするための一時的な順守ポリシーの、左の緑●をクリックし無効化します。

既存の順守ポリシーの、右の鉛筆アイコンをクリックします。[4 概要]を選択して[完了してアクティブ化]をクリックします。

Windows 10デバイスが[順守状態]であることを確認します。

Windows 10デバイスでHubアプリカタログのセルフサービスポータルをクリックします。デバイスが順守状態に戻れば正常にアクセスできることを確認します。

振り返り

今回の作業ではデバイス順守を構成し、SAML連携ウェブアプリケーションの利用時にデバイスの順守状態をチェックしました。デバイスが非順守状態の場合、SAML連携ウェブアプリの利用ができないことを確認しました。

まとめ

本連載で例示したように、Workspace ONE AccessとOffice 365やSalesforceなどの企業SaaSアプリケーションをSAML連携し、証明書認証とデバイスコンプライアンスを構成することで、

• Workspace ONEに加入している(管理されている)
• ユーザー証明書が配布されている
• 順守状態である

といった条件を満たすWindows 10デバイスだけが企業SaaSアプリケーションを安全に利用することができる、ゼロトラスト セキュリティを実現することができます。内勤職が利用する会社内のデスクトップPCから、営業職やフィールドエンジニアが外出先で利用するラップトップPCまで、すべての企業ユースケースに対応することができます。

本連載は以上となります。皆様のWindows 10管理をオンプレミス依存のレガシーPCLMから脱却させ、最新の管理(モダンマネジメント)へ移行する一助となれば幸いです。

The post Windows 10モダンマネジメントガイド 第10回 デバイスコンプライアンスの構成 appeared first on VMware Japan Blog.

はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回は「触りながら学ぶ  vSphere with Tanzu」シリーズの第三回として vSphere with Tanzu を管理者と操作して開発者に Kubernetes 環境を提供する方法を学びます。これを学ぶことでスーパーバイザークラスタの概念や、なぜセルフサービス型のK8s運用が優れているかといった点を理解できます。

Tanzu Kubernetes Grid （TKG） の基本的なコンセプトは K8s の利用者（開発者と運用者の両方）にたいして、セルフサービス型の K8s 基盤を提供するというもので、K8s を利用したいユーザーが自分自身でクラスタを展開/変更（スケールやアップグレード）/削除できます。これは vSphere7 に組み込まれる vSphere with Tanzu （別名TKGS: Tanzu Kubernetes Grid Service）でも、AWS や Azure などで利用される TKGm （TKG multicloud） でも同様です。誰かになにかの作業を頼まないでよいセルフサービス型の K8s 基盤は開発者にとっても、運用者にとってもメリットがあります。セルフサービス機能の有無による違いを以下の図に記載します。

たとえば図の左側のようにセルフサービスでない K8s 基盤の払い出しをするとしましょう。K8s が必要になるたびに運用者は要件にしたがって K8s クラスタを定められた手順に従って作成します。原始的な作成方法であれば、ベアメタルか仮想マシンとして Linux を数台作成し、それに K8s に必要なパッケージをインストールしてからツールを使ってクラスタを構築することになります。もう少しスマートな方法を採用すれば GUI なり CLI なりで決められた要件に沿ったクラスタを自動で構築できますので、労力は減ります。ただし、IT エンジニアが数百人以上いる組織においてプロジェクトごとに複数のクラスタを構築し、それをアップデートしたり、破棄（資源の回収）する作業は膨大になります。それを運用チームがすべて引き受けて実施していれば、利用者にクラスタを作成して渡すにも時間がかかりますし、サイズ変更やアップデートなども即座には実施できないでしょう。運用チームにとっても多くの仕事依頼に忙殺されることになります。

一方、図の右側のようにセルフサービスな K8s 基盤の払い出しをするのであれば、K8s を必要とする人が自分自身で作成を実施できます。開発者視点では即時に環境の払い出しや構成変更（スケールやバージョン）を行えるというメリットがあり、運用者視点では環境払い出しに人的なリソースを奪われないというメリットがあります。TKG が図の左側で運用者が実施していた作業をプラットフォームとして自動で実施しています。このようなK8s自体をサービスのように利用者が使うことができる基盤は「KaaS（Kubernetes as a Service）」と呼ばれることがあります。

私の個人的な意見となりますが、たとえば開発環境の K8s クラスタは本番環境に比べるとかなり荒く利用することが多いです。拾ってきたYAMLをとりあえず展開してみたり、勉強中の機能を見様見真似で導入することを頻繁に実施したりします。そうすると、使っているK8sクラスタの環境はすぐに汚れてしまいます。もし左側のような運用方法で K8s を使っていれば、運用者にクラスタ再構築を依頼することに気が引けるので、クラスタを汚さないように気をつけますし、汚れてしまったら手動で頑張って戻そうとします。ただ、新しいことを試したい状況ではそういった利用法は開発者にとって負担となるはずです。一方で右側の例のように TKG では簡単にK8s環境を自分で管理できます。そのため「K8sクラスタをガチャガチャ触って、汚れたり、壊れたり、新しいことを試したくなったら新規に作り直す」ということを気兼ねなく実施できます。これは利用者にとってありがたいことなのではないかと思います。運用者にとっても壊れたクラスタの復旧依頼や再構築依頼が減るでしょう。

この記事では TKGS のスーパーバイザーネームスペースを使ったセルフサービス基盤をどのように設定するかを紹介します。ネームスペース機能を使うことで、TKGS 上の「TKC の作成」「vSphere Pod の作成」といった利用者操作を「誰が」「何を」できるかといったことや、「どの永続ストレージを使うか」「どれほどのCPU/メモリ/ストレージリソースを使えるか」といったことを定義できます。

スーパーバイザークラスタの構成確認

このシリーズの第1-2回でも紹介しましたが、vSphere with Tanzu の構成を復習します。vSphere Tanzu には「スーパーバイザークラスタ」と呼ばれるK8sを管理するための K8s がいます。そしてスーパーバイザークラスタには「スーパーバイザーネームスペース」という VMware の仮想マシンのリソースプールと一般的な K8s のネームスペースを合わせたような管理単位があります。このスーパーバイザーネームスペースの上に第一回で紹介した「Tanzu Kubernetes Cluster（TKC）と呼ばれるワークロード K8s クラスタ」を展開したり、第二回で紹介した「ESXi 上に Pod を超軽量仮想マシンとして K8s 的に展開する vSphere Pod」を展開したりします。以下にこの概念図を記載します。

Tanzu の管理者（運用者）の仕事は、「利用者にスーパーバイザーネームスペースを提供する」ことです。具体的には「ネームスペースを作成する」操作をし、「誰がどういった権限でネームスペースにアクセスできるか」「ネームスペース上のコンテナはどのデータストアを利用するか」「CPU やメモリ、ストレージをどれだけ利用できるか」といったことを設定します。あとは設定されたスーパーバイザーネームスペースを実際のK8s の利用者（開発環境 K8s を使う開発者や本番環境 K8s を使う運用者など）に渡して、それが正しく使われているか従来の仮想マシン環境と同じようにネームスペースレベルでモニタリングを実施するだけです。

この記事では前回までの記事のように VMware が提供するハンズオンラボ環境の「HOL-2113-01-SDC – vSphere with Tanzu」を使って、まずスーパーバイザークラスタの構成を確認したうえで、上記の管理者としての操作であるスーパーバイザーネームスペースの管理と作成を行います。ハンズオン環境の利用法は当シリーズの第一回の記事をご参照ください。

触りながら学ぶ vSphere with Tanzu 第1回: Tanzu Kubernetes Cluster

まず、管理者としてvCenterに接続するためにモジュール2の「The Supervisor Cluster」の「Log into vCenter」にしたがって、vSphere Client にログインしてください。ログインしてクラスタとホスト一覧のページを確認すると以下のような状況となっているはずです。

この図にあるようにクラスタ「RegionA01-COMP01」の下に Namespaces があります。これは vSphere7 で vSphere with Tanzu（TKGS）の機能を有効化した際に現れるスーパーバイザーネームスペースの一覧となります。このHOLでは最初から「demo-app-01」というネームスペースが作成されていますが、機能を有効化した直後の状態では空になっています。スーパーバイザーネームスペースの下にある「SupervisorControlPlaneVM」が、TKGSの機能を実現するアプライアンスVMとなり、これらも vSphere7 で TKGS の機能を有効化した際に自動で作成されます。この VM たちはTKGSが提供する機能を実現するためのサービスを動かしており、これら自身も K8s クラスタを構築して動作しています。第一回の TKC 作成や第二回の vSphere Pod の作成のさいに「kubectl vsphere login」コマンドを使ってスーパーバイザークラスタにログインを実施しましたが、実はその接続先はこれらの VM が動かす管理用の K8s クラスタです。このスーパーバイザークラスタがどういうものかは深く知らなくても運用はできますが、以下に簡単な構成図を記載します。

図にあるように一般的な vSphere 環境と同じように vCenter が複数の ESXi を束ねるという構成をとっています。注目して欲しいのは ESXi の中にある「K8s Control Plane VM」であり、これがさきほど紹介したアプライアンス VM となります。アプライアンス VM は全ホストに展開されるのではなく、K8s クラスタ構築に必要な3台が vSphere クラスタを構成する ESXi のどれかに配置されます。このアプライアンス VM のサイズはvCenter などと同様に管理する vSphere Pod や TKC の数が増えるほど大きくなります。

図の右上にこの VM の内部構成があり、K8s ユーザーには見慣れたコンポーネントが並んでいることが確認できます。また、ESXi ホスト自身と vCenter にたいしても TKGS の機能を実現するためのコンポーネントが追加されており、特に重要なものとしては vSphere Pod を実現するために ESXi の内部に Spherelet（kubelet）が置かれていることが挙げられます。この Spherelet があることで、スーパーバイザークラスタは ESXi ホストをワーカーノードのように扱って K8s ポッドを vSphere Pod として作成できるようになっています。

また、管理者やユーザーとして知っておくべきことは、このスーパーバイザークラスタを構成する VM は「マネージメント用のネットワーク」と「ワークロード用のネットワーク」に接続されているということです。前者は図で「Management vNIC」と書かれたものであり、後者は「NSX Cluster vNIC」と書かれたものです。これらをどう設定するかは機能を有効化する際に指定しますが、その設定は「vSphere クラスタ（スーパーバイザークラスタではないので注意）」の設定（Config）にある Namespace から確認できます。2020年12月時点で多くの項目は構築後に変更できませんので、最初のネットワーク設計はきちんと実施してください。

なお、このスーパーバイザークラスタのIPアドレスはメニューの「Workload Management」から「Clusters」タブで確認できます。以下の例では「192.168.124.1」となります。「kubectl vsphere login」で接続する際に利用する重要なパラメーターですので確認方法は覚えておいてください。

スーパーバイザーネームスペースの確認

アクセス頂いている vSphere ではすでに vSphere with Tanzu が有効化されており、スーパーバイザーネームスペースも作成されています。そのネームスペース「demo-app-01」を使って、ネームスペースの設定確認をしながら機能説明をおこないます。マウスで「demo-app-01」をクリックすると以下のような画面が表示されるはずです。

上記の図で番号を与えている箇所はそれぞれ以下の表示をしています。

1. ネームスペース設定の機能ごとのタブ。Summary で機能一覧の状況が確認できる
2. スーパーバイザークラスタの稼働状況
3. ネームスペースに編集（edit）/閲覧（view）権限を持つユーザー。ここにないユーザーはアクセスできない
4. ネームスペースに割り当てられたストレージポリシー（vSphereのデータストア指定などに使う）と作成されたPVCの数
5. ネームスペースで使われている TKC と vSphere Pod の合計リソース
6. ネームスペースで動いている vSphere Pod の数と稼働状況
7. ネームスペース上に構築されている TKC（ワークロードクラスタ）の数

それぞれに表示される Manage や Edit ボタンからこれらの設定を変更することができますし、上記の Summary があるタブから各項目の画面で詳細を確認したり設定変更することも可能です。各項目ごとに詳細説明すると記事が長くなりすぎるので割愛しますが、クリック操作でそれぞれどういった項目があるかチェックしてもらったり、オリジナルの HOL のモジュール2の「Supervisor Cluster Namespaces」に沿って操作をしていけば、どういった機能があるかを確認してもらえます。お時間がある際に試してみてください。

スーパーバイザーネームスペースの作成と編集

アクセスコントロールやリソースの管理はスーパーバイザーネームスペース単位で実施します。K8s の利用者1人ごとにネームスペースを与えれば、その人だけが使える環境が用意できます。また、作成したネームスペースに複数の利用者アカウントを結びつけることで、チームで共有する環境を用意することもできます。実際にネームスペースの作成をおこないながら、どういうかたちでネームスペースを使うがよいかを説明していきます。ここで紹介する利用法の詳細は以下のドキュメントをご参照ください。

スーパーバイザー ネームスペース の作成と設定

まず、ネームスペースの作成をおこなうために vSphere Client のページ上部ナビゲーションにある Menu（メニュー）から「Workload Management」を選択し、スーパーバイザークラスタの管理ページに移動します。

このページはスーパーバイザークラスタの有効化（スーパーバイザークラスタの作成）や更新にも利用しますが、ここからネームスペースの管理（作成/変更/削除）も実施できます。上記図では既存のネームスペースが選択されていないので、「New Namespace」のみ表示されていますが、下の表で選択すれば変更や削除（上で動く TKC や vSphere Pod もまとめて削除）を実施できます。今回は作成するので、「New Namespace」をクリックします。

クリックすると、vCenter が管理するどのデータセンターのどの vSphere クラスタ上にネームスペースを作成するか聞かれるので、上記図の1-2のように選びます。そしてネームスペース名をと必要であれば概要（description）を入力し、Create ボタンを押すとネームスペースが作成できます。

ネームスペースを作成すると既存の「demo-app-01」と同じように「demo-app-02」がメニューのクラスタとホストの一覧のなかに表示されるようになります。さきほど demo-app-01 を確認したように demo-app-02 をクリックしてネームスペースの状況を表示し、ネームスペースの初期設定作業を実施します。ネームスペースを利用するために必須なのは Permission と Storage の設定のみで、それ以外のリソースコントロールなどは必要であれば設定する項目となります。

上記図の Add Permissions を押すと、登録するユーザーの入力画面が出ますので、誰が、何（Edit/View）をできるか入力してOKボタンをクリックします。このユーザー登録作業を必要なだけ繰り返します。なお、ここに入力されるユーザーは vSphere に登録されているユーザーです。外部（LDAPなど）で管理されないユーザーであれば、メニューの設定（Administration）から「Single Sign On」「Users and Groups」と進むことでユーザー管理をおこなえます。詳細は vSphere のドキュメントを参照ください。

vCenter Single Sign-On ユーザーの追加

次にスーパーバイザーネームスペース上の TKC と vSphere Pod が利用できるデータストアの指定をおこないます。これはネームスペース設定画面の「Add Storage」ボタンからストレージポリシーの設定をすることでおこないます。今回は「high-performance-ssd」を指定します。

なお、今回は事前にストレージポリシーが用意されていましたが、新規構築する場合は新しく「データストアを特定するためのストレージポリシー」を作成する必要があります。それには以下の画像のように利用したいストレージにたいして識別子となるタグを与えたうえで、メニューから「Policies and Profiles」に進み、VM Storage Policies で新規にストレージポリシーを作成することで実施します。ポリシー作成のさいに先ほどデータストアに与えたタグを利用するように指定すれば、選択したデータストアを指定できるストレージポリシーが作成できます。

vSphere with Tanzuのストレージ ポリシーの作成

kubectl vsphere コマンドのインストール案内

最後に第1-2回で利用していた kubectl vsphere コマンドの設定方法について扱います。このコマンドは Linux のパッケージ管理や Docker Desktop のインストールをしただけでは利用できません。VMware から入手した kubectl の実行ファイル（バイナリ）もしくはすでにご利用の kubectl のバイナリにたいして、「kubectl-vsphere」というプラグインを追加することで使えるようになります。運用者のかたは TKGS の利用者にたいして「どのURLでプラグインを入手して、それをOSのどこに配置することで kubectl vsphere コマンドが使えるようになるか」ということを伝えてください。詳細は後述するドキュメントをご参照いただきたいですが、vSphere Client の「namespace -> summary -> status -> link to cli status」で確認できる「Kubernetes CLI Tools」のダウンロードページの URL を利用者に送り、そこでダウンロードしたバイナリ（Windows/Mac/Linux）をkubectlバイナリがある「パスが通っているディレクトリ」に配置することになります。

vSphere 向け Kubernetes CLI Tools のダウンロードとインストール

以上で管理者としてのネームスペース機能の概念と利用法の紹介記事を終了します。作成されたネームスペースへの接続方法は第一回の TKC の記事にて説明していますので、そちらを参照してください。次回の第4回は TKGS がどのように構成されているかという座学よりの内容を扱う予定です。ご拝読ありがとうございました。

The post 触りながら学ぶ vSphere with Tanzu 第3回: 管理者としての操作 appeared first on VMware Japan Blog.

はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。今回は「触りながら学ぶ  vSphere with Tanzu」シリーズの第二回として vSphere Pod を操作しながら機能説明します。

vSphere Pod は一言で言ってしまうと VMware vSphere を構成する ESXi ホスト上で直接 Kubernetes （K8s）のワークロードを実行する技術です。おそらく多くの Kubernetes 実行環境は本シリーズの第一回で説明した「Tanzu Kubernetes Cluster（TKC）」と同じように「仮想マシンとして K8s のノード群をたちあげてクラスタを構築し、そのうえでコンテナを動かす」という構成かと思います。つまり、仮想マシンとコンテナという2階建ての構成になっているということです。一方、vSphere Pod はコンテナ用途に最適化された超軽量仮想マシンのうえでワークロード（Pod）を直接実行するという VMware ならではのテクノロジーです。

上記の図にあるように「Pod が ESXi 上で仮想マシンとして直接実行される」形態をとっています。言い方を変えると普通の K8s のように「ワーカーノード上に複数の Pod が共存する」という実行形式をとりません。そのため、Podレベルのパフォーマンスやアイソレーションに優れているという特徴があります。また、非常に小さいアプリケーションを動かすのに必要なリソースがTKC（冗長性を持ったマスターとワーカーノードを展開）に比べると小さいという特徴もあります。

ただし、注意が必要なのは「vSphere Pod が提供する K8s の機能が豊富ではない」という点です。たとえばHelmやIstioなどはvSphere Pod では利用できません。そういった背景がありますので、「vSphere with Tanzu で利用する K8s クラスタは、デフォルトでは一般的な K8s クラスタである TKC を利用する」とご認識ください。一般的な K8s アプリケーションが vSphere Pod では動作しない可能性があります。vSphere Pod の利用を検討する状況は、後ほど紹介する利用が適した場面とお考えください。

vSphere Pod の概念と使い所

vSphere Pod はスーパーバイザーネームスペース上に一般的な K8s の Pod リソースと同様に展開されます。実際にはDeployment や Service リソースなどとともに利用されるでしょうが、その使い方は YAML で定義して kubectl apply コマンドで適用するという標準的な使い方です。また、ネームスペースレベルでどれだけのリソースが使えて、誰がアクセスできるか決めれるのも K8s らしい使い方です。このように、vSphere Pod がワークロードをどのように動かすかということは特殊であるものの、ユーザーとしての使い方は普通の K8s と大差ありません。このあたりは実際に機器を操作するなかで体感していただければと思います。

TKCは操作体系だけでなく内部構成も一般的な K8s ですので、ほとんどのユースケースに合致します。一方で、vSphere Pod は使うべき場面が限定的です。2020年12月時点では推奨される利用場面は以下が求められる場合です。詳しくはドキュメントを参照ください。

• TKCのノード(マスター/ワーカー)が使用するCPUやメモリを削減したい。ESXi上で直接K8s Podを動作させるので、TKCのK8sノードとなる仮想マシン自体にリソースを使われません
• Podレベルでの独立性が必要な場合。1つのPodに問題が起きても仮想マシンレベルで独立しているため、他のポッドに影響がありません
• 1つのポッドで高いパフォーマンスが求められる場合。通常のK8sのポッドに比べて vSphere Pod は低いレイヤで動作します。マシンパワーや内部ネットワークのオーバーヘッドを減らせます。低遅延が求められたりモンスターPod（超巨大なPod）のような使い方をしたい場合です
• Podを従来の仮想マシンのように監視したい場合。vCenterで直接監視できます

vSphere Podには上記のような強みがある一方で、VMware の独自色が強いことに起因する弱点もあります。一番大きなものとしては、シンプルな使い方（サービスとデプロイメント及びネットワークとストレージの利用など）以外では機能的な制約によりワークロードを実行できない可能性が標準的な K8s である TKC に比べると高いことです。たとえばIstioなどは利用できません。また、vSphere流の監視ができる一方で、K8s流のモニタリングは難しくなります。その次にTKCと異なり、様々な利用者が同じスーパーバイザークラスター上でワークロードを展開するため、1つのK8sクラスタが管理するワークロードが多くなりがちという問題点もあります。TKCはクラスタレベルで完全にワークロードを分離できますが、vSphere Podはそれができません。繰り返しますが、2020年12月時点では「TKGS上で利用する K8s クラスタのデフォルトは TKC とし、vSphere Pod はそれが必要な場面以外では利用しない」という運用をおすすめします。なお、vSphere Podは今後も機能拡張していく予定ですので、将来的にはその用途が増えることが予想されます。

vSphere Pod の展開

ここからは実際に弊社が提供するラボ環境で vSphere Pod を利用してもらうことで、その機能を実体験していただきたいと思います。以下のシナリオで進めていきます。

1. VMware の HOL（Hands On Lab）のサイトにアクセスする
2. vSphere with Tanzu のラボを開始する
3. vSphere Pod のモジュール3（演習）に進む
4. vSphere Client 上でスーパーバイザークラスターの構成を確認する
5. kubectlコマンドでスーパーバイザークラスターに接続する
6. vSphere Pod のワークロード（ウェブアプリ）を展開
7. 展開したアプリにブラウザでアクセス
8. vSphere Client 上で vSphere Pod の VM（Pod, コンテナ用）を確認

まず、上記ステップの1から3ですが、これは前回の記事に書いた HOL へのアクセス法を参照してください。

触りながら学ぶ vSphere with Tanzu 第1回: Tanzu Kubernetes Cluster

モジュール3にある「LOG IN TO VCENTER」を参照して、vSphere Client にログインします。そして、メニューの「Hosts and Clusters（おそらく初期画面がこれ）」から Namespaces（スーパーバイザーネームスペース一覧）および demo-app-01（スーパーバイザーネームスペースの1つ）を開きます。そうすると TKC である tkg-cluster-01 の下に3つの hello-kubernetes… という VM のようなものが見えると思いますが、これがvSphere Podです。

次に自分で vSphere Pod を展開します。そのためには、まずモジュール3の「LOGIN TO SUPERVISOR CLUSTER」に従って、kubectl コマンドでスーパーバイザークラスターにログインをおこないます。このコマンドの解説はシリーズ第一回で説明していますが、vSphere with Tanzu のIPを指定して、ユーザー名を指定してログインします。ログインすると Kubernetes のコンテキスト（複数のK8s環境を使い分けるための標準的な仕組み）が得られるので、スーパーバイザーコンテキストを指定してスーパーバイザークラスタを操作できる状態にします。

上記の例では接続先のスーパーバイザークラスターの IP は 192.168.124.1 であり、接続ユーザーは administrator@corp.local です。そうすると、ユーザーが属するネームスペースである「demo-app-01」のコンテキストが得られました。そして、そのコンテキストに変更しています。

次に自分のアプリケーションを vSphere Podとして展開します。前回の復習も兼ねて説明すると「TKC のコンテキストで kubectl を使ってポッドを展開すると、TKC 上にポッドが展開される」「スーパーバイザーのネームスペースでポッドを展開すると、vSphere Pod がそのスーパーバイザーネームスペース上に展開される」という動きをします。サンプルアプリのマニュフェストが「~/labs/guestbook」にあるので、それを kubectl apply コマンドで展開してみます。

kubectl get pods コマンドや kubectl get svc コマンドの結果から、kubectl apply コマンドにより Pod（Deployment）と Service のリソースが展開されたことが確認できます。Pod が起動するまでに少し時間がかかっていますが、これはポッドの初回利用イメージを取得するダウンロード時間などが含まれるためです。サービス確認コマンドで確認しているサービスのタイプ:ロードバランザーとして公開された IP:192.168.124.3 （みなさまの環境では違うIPの可能性が高いです）にブラウザでアクセスすると、さきほど apply によりデプロイしたウェブサービスが動作していることが確認できます。

このアプリケーションを構成する Pod（コンテナ）は  vSphere Pod （vSphereの超軽量仮想マシン）として展開されているので、それを vSphere Client で確認してみます。今回利用したスーパーバイザークラスターの「demo-app-01」というネームスペースに着目してください。

先ほど確認した時に存在しなかった「frontend」「redis-master」「redis-slave」という3つの vSphere Pod が展開されていることが確認できました。これらは先ほど apply したマニュフェスト内で定義されています。

最後に展開したアプリケーションを通常の K8s のリソースのように削除をおこないます。kubectl delete でマニュフェストを指定してリソース削除をすると、CLI のレスポンスとしてリソースが削除されたことが確認でき、それに加えて vSphere Client 上からも vSphere Pod が削除されていることが確認できます。

以上で本記事の vSphere Pod の基本的な機能紹介を終えたいと思います。第1,2回は開発者目線の操作を中心に説明してきましたが、第3回では運用者側の視点で vSphere with Tanzu の管理と操作について紹介したいと思います。ご拝読ありがとうございました。

The post 触りながら学ぶ vSphere with Tanzu 第2回: vSphere Pod appeared first on VMware Japan Blog.

TAM契約をお持ちの皆様、こんにちは。

こちらのBlogでは、現在、各担当TAMよりお願いしているTAM Data Manager（以降TDMと表記）の
取得手順についてご案内いたします。
（なお、本Blog では、TDM ver. 2.5.0 Build:16991226 の取得手順についてご案内いたします。）

ご対応、どうぞよろしくお願いいたします。

目次

• • TDM の目的
  • TDM ツール の入手
  • TDM ツール 事前要件
  • TDM ツール 実行手順
  • FAQ

TDMの目的

現状の VMware vSphere / VMware Horizon 環境の規模・構成を把握する為のレポートで、ホスト数、VM 数、ホストの CPU 数、VM 種別、バージョン、データストア毎の VM 数、メモリ使用状況、ライセンス情報等の情報が確認できます。
通常、TAM サービス開始以後、3か月毎に確認させて頂いております。
送付頂いた情報を弊社内のDBに登録し、その情報をもとに WorldWide の TAM 契約顧客のレポート(TAM Quarterly Customer Intelligence Dashboard)が作成されます。

TDM ツール の入手

担当 TAM よりご案内いたします。

TDM ツール 事前要件

TDM ツールを実行するには、以下の要件を満たす作業端末が必要です。

プラットフォーム

• Microsoft Windows Server 2008 以降
• Microsoft Windows 7 以降（64 bit）
• Apple Mac OS X （Lion, Mountain Lion, Mavericks, Yosemite, or El Capitan）

メモリ

• 4GB 以上を推奨

ブラウザ

• Microsoft Internet Explorer（TDM 2.5.0 より非対応）
• Microsoft Edge
• Google Chrome
• Mozilla Firefox

ネットワーク

• vCenter Server と ESXi に到達可能であること。

アクセス権

• vCenter Server にアクセス可能な権限を持つユーザーアカウント情報。
  ＊オブジェクトを参照するのみで、作成・修正・削除は行いません。

Java Runtime Environment (JRE)

• JRE 11.0.8
  or
• OpenJDK 11 （64 bit）
  https://adoptopenjdk.net/upstream.html?variant=openjdk11&ga=ga
  ＊以前のバージョンの TDM ツールの実行には、JRE 1.8 以上が必要でしたが、
  バージョン2.5.0 からは JRE 11.0.8 が必要です。
  ＊Oracle 社のJava ライセンス有償化に伴い JRE 11.0.8 のご用意が難しい場合には、
  無償版のOpenJDK 11をご利用ください。

TDM ツール実行手順

以下、Windows OS を作業端末とした際の手順についてご案内いたします。

① 作業端末に JRE 11.0.8 もしくは OpenJDK 11 （64 bit）が
インストールされていることを確認してください。

②「tdm-PRODUCTION-2.5.0-GA-build-xxxxxxx-Java.zip」を作業マシン上に解凍し、
下記フォルダが揃っていることを確認の上、
「VMware TAM Data Manager.jar」をダブルクリックして実行してください。

③ ウィンドウが立ち上がりますので、
「App Server」、「Database Server」が「Running」になったら「Connect」をクリックしてください。
ブラウザが自動的に起動します。
＊エラー等が発生した場合には、FAQ をご参照ください or 担当 TAM にご連絡ください。

④（初回起動時のみ）EULA が表示されたら、「I agree」をクリックしてください。

⑤「Welcome to TAM Data Manager」の画面が表示されたら、
「User」「Password」欄に「Customer」と入力し、「LOCAL LOGIN」をクリックしてください。

⑥ TDM ツールのメイン画面にて、左ペインのトップにある「Add」から、
「New TAM CI Project」をクリックしてください。

⑦「New TAM CI Project」の画面にて、
以下を参照に「Main Detailes」、「Choose vCenters」や「Choose Horizon View Servers」、
「Customer Agreement」を入力してください。

⑧「Ready to complete」にて、「Finish」をクリックし、データの取得を開始してください。

⑨ TDM ツールのメイン画面に、以下の通り取得状況の「Status」が表示されます。
「Status」にチェックマークがつけば、取得完了です。

⑩ 以下を参照に、収集したデータをエクスポートし、データを担当 TAM へお送りください。
送付方法は担当 TAM とご相談ください。

FAQ

ツールについて

[Q]
ツール実行時の負荷はどれくらいですか？
[A]
TDM ツールは vCenter Server にアクセスしオブジェクトを参照するのみであるため、
一般的に低負荷で稼働します。
詳細やご利用環境における差異については担当 TAM へご相談ください。

[Q]
ツールが取得するデータを教えてください。
[A]
下図を参照してください。
ホスト数、VM 数、ホストの CPU 数、VM 種別、バージョン、
データストア毎の VM 数、メモリ使用状況、ライセンス情報等を取得し、
ユーザ名やパスワードなどのアカウント情報は取得しません。

エラーについて

[Q]
Database Server が起動しません /  ログファイルに下記エラーが表示されました。
” Error occurred during initialization of VMCould not reserve enough space for 1310720KB object heap ”
[A]
JRE 11.0.8 or OpenJDK 11 の 64 bit版をインストールしてください。

起動時の問題について

[Q]
「VMware TAM Data Manager.jar」起動後、
「Connect」をクリックしてもブラウザが正常に表示されません。
[A]
ブラウザのキャッシュクリアを実施し、再度試みてください。

[Q]
「VMware TAM Data Manager.jar」起動後、「App Server」が「Running」になりません。
[A]
２〜３分ほどお待ち下さい。
２〜３分経過しても状態が変わらない場合、ブラウザで以下に直接アクセスしてください。
http://localhost:8080/

[Q]
ツールが起動できません。
[A]
画面のスクリーンショットと以下のログを取得の上、担当TAMにご相談ください。
<TDM instance folder>/logs 配下にあるログ全て

///

以上、TDM ツールについてのご案内でした。
ご不明な点などございましたら、担当 TAM までご連絡ください。
どうぞよろしくお願いいたします。

VMware TAM高松＆皆川

The post [TAM Blog] TAM Data Manager（TDM）取得手順のご案内 appeared first on VMware Japan Blog.

はじめに

弊社Techzoneに掲載の ”Deploying VMware Workspace ONE Tunnel: VMware Workspace ONE Operational Tutorial (運用チュートリアル: VMware Workspace ONE トンネルの展開)” の理解の一助とすべく、日本語での手順概要とスクリーンショットをご提供いたします。

概要

会社のDMZにVMware Unified Access Gatewayを展開し、トンネルエッジサービスを構成します。インターネットにあるデバイスからアプリケーション単位のトンネルを通じて会社内へのリソースアクセスを構成します。

VMware vSphere環境へのUnified Access Gatewayの展開については、弊社Techzoneに掲載の” Configuring the VMware Tunnel Edge Service: VMware Workspace ONE Operational Tutorial (運用チュートリアル: Workspace ONE トンネル エッジサービスの構成)”も合わせて参照ください。本ドキュメントではUnified Access Gatewayの展開手順については触れません。

Unified Access Gateway のドキュメント

Unified Access Gateway への VMware Tunnel のデプロイ

アプリケーション単位のトンネル機能およびUnified Access GatewayはVMware Workspace ONEの特定のエディションにバンドルされています。

VMware Workspace ONE のエディションの比較

Unified Access Gatewayトンネルエッジサービスの構成

VMware Workspace ONE UEMでトンネル構成を、またDMZに展開したUnified Access Gatewayでトンネルエッジサービスを構成します。Workspace ONE UEMにてUnified Access Gatewayへの接続テストを行い、トンネルエッジサービスが正しく構成されていることを確認します。

Windows 10向けWorkspace ONE Tunnelの展開

Workspace ONE UEMにてデバイストラフィック規則を構成し、[リモートデスクトップ接続]アプリ(mstsc.exe)をアプリケーション単位のトンネルの対象に、また宛先がad01.awafw.localの際にだけトンネル(トラフィックがVPN網を通過)するよう指定します。

Windows 10向けWorkspace ONE Tunnelアプリの配信

My Workspace ONEにログインし、Windows 10向けWorkspace ONE Tunnelアプリのexe形式インストーラーを入手します。

インストールコマンドオプションを得る

exe形式インストーラーの場合、コマンドプロンプトにて /help や /? を付けて実行するとインストールコマンドオプションを表示することができます。アプリケーションのドキュメントに記載されている場合もあります。

Windows 10向けWorkspace ONE Tunnelアプリのアップロード

Workspace ONE UEMのアプリ配信機能を用いて、Windows 10向けWorkspace ONE Tunnelアプリを加入済みデバイスに配信します。

Windows 10向けPer-App VPNプロファイルの作成

Windows 10向けPer-App VPNデバイスプロファイルを作成します。UAGでワイルドカードSSL/TLS証明書を用いている際にはカスタム構成XML項目も指定します。

Windows 10でPer-App VPNトンネルのテスト

Windows 10で、VMware Workspace ONE Intelligent Hubアプリカタログから[VMware Workspace ONE Tunnel]をインストールします。必要に応じてWindows 10を再起動します。

[リモートデスクトップ接続]アプリを起動します。ad01.awafw.localへの接続を試行するとWorkspace ONE Tunnelが自動接続し、リモートデスクトップに成功します。この際、デバイスが順守状態にある際にだけアプリケーション単位のトンネル接続が確立します。

振り返り

本コンテンツで例示したようにアプリケーション単位のトンネルを構成することで、以下の条件を満たす際に、指定されたアプリケーションが指定された宛先へ通信を行う際にだけ、アプリケーション単位のトンネルが自動接続します。

• Workspace ONE に加入している(管理されている) Windows 10である
• Per-App VPNプロファイルが配布されている
• 順守状態である

デバイス全体のトラフィックがVPNを通じて企業データセンターへ向かうことなく、特定のアプリケーションだけを安全に利用することができる、ゼロトラスト セキュリティを実現することができます。

The post Windows 10モダンマネジメントガイド 番外編 アプリケーション単位のトンネルを用いた社内リソースへのアクセス appeared first on VMware Japan Blog.

はじめに

VMware Workspace ONEを用いてクラウドからWindows 10を管理、ゼロトラスト セキュリティを実現する「最新の管理(モダンマネジメント)」体験の連載のまとめです。

この連載を実践することで、以下を体験することができます。

• VMware Workspace ONEとオンプレミスActive Directoryを連携
• 階層構造を用いたデバイス管理
• Windows 10を加入
• 構成プロファイルを配信し様々な設定をリモート構成
• 順守ポリシーでデバイス状態をチェック
• 順守ポリシーで非順守デバイスの復旧アクションを自動化
• ベースラインで企業デバイスのセキュリティを強化
• Win32 アプリケーションを配信
• SAML連携ウェブアプリケーションへシングルサインオン
• 証明書認証およびデバイスコンプライアンスを構成
• アプリケーション単位のトンネル Per-App VPN

第1回 無償評価版の入手
https://blogs.vmware.com/vmware-japan/2020/11/dw-windows10mm_1st.html

Workspace ONEの要件を確認し、フリートライアル版の申込みを行います。送付されるアクティベーションメールの情報を用いてWorkspace ONE UEMおよびWorkspace ONE Accessコンソールにログインします。

第2回 オンプレミスActive Directoryとの連携
https://blogs.vmware.com/vmware-japan/2020/11/dw-windows10mm_2nd.html

ウィザードを用いてオンプレミスActive Directoryとの連携を行います。Active DirectoryからVMware Workspace ONE UEMへ、更にVMware Workspace ONE Accessへディレクトリユーザーやグループを連携します。

第3回 Active DirectoryユーザーをWorkspace ONE UEM/Accessへ連携
https://blogs.vmware.com/vmware-japan/2020/11/dw-windows10mm_3rd.html

オンプレミスActive DirectoryのドメインユーザーをVMware Workspace ONE UEMのディレクトリユーザーとして追加します。Active Directoryの組織ユニット(OU)を、Workspace ONE UEMのユーザーグループとして追加します。Workspace ONE UEMのディレクトリユーザーやユーザーグループを、VMware Workspace ONE Accessに連携します。

第4回 階層構造を用いた管理の構成
https://blogs.vmware.com/vmware-japan/2020/11/dw-windows10mm_4th.html

Workspace ONE UEMの特徴のひとつである階層構造を用いた管理を構成します。サブ組織グループや管理者アカウントを作成します。Active Directoryのドメインユーザーを一括してWorkspace ONE UEMへディレクトリユーザーとして追加します。加入ユーザーの所属ユーザーグループに基づいて、加入デバイスが適切な組織グループに配置されるよう構成します。

第5回 Windows 10の加入とプロファイル配信
https://blogs.vmware.com/vmware-japan/2020/12/dw-windows10mm_5th.html

VMware Workspace ONE Intelligent Hubを用いてWindows 10をWorkspace ONE UEMに加入します。Windows デスクトップ プロファイルを追加し、BitLocker、Windows Defender、Windows Update、制限などの様々な構成をWindows 10へ配信します。

第6回 順守ポリシーの構成
https://blogs.vmware.com/vmware-japan/2020/12/dw-windows10mm_6th.html

順守ポリシーを構成し、エンドユーザーへの通知などを自動化します。また無効化されたファイアウォールの復旧アクションを自動化する順守プロファイルを作成、適用します。

第7回 ベースラインの構成
https://blogs.vmware.com/vmware-japan/2020/12/dw-windows10mm_7th.html

ベースラインを構成し、カスタマイズでレジストリエディター起動禁止を追加します。ベースラインをWindows 10へ配信し、ベースラインが適用されていることを確認します。

第8回 Win32 アプリ配信
https://blogs.vmware.com/vmware-japan/2020/12/dw-windows10mm_8th.html

Win32アプリケーションを簡単に企業アプリリポジトリから追加します。加入したデバイスに自動でインストールされるタイプ、ユーザー自身がHubアプリカタログから選択してインストールできるオンデマンド配信タイプを確認します。

第9回 SAML連携ウェブアプリへのシングルサインオン
https://blogs.vmware.com/vmware-japan/2020/12/dw-windows10mm_9th.html

SAML連携ウェブアプリケーションへのシングルサインオンを構成します。エンドユーザーはVMware Workspace ONE Intelligent Hubアプリカタログからウェブアプリをクリックするだけで、証明書認証によりユーザー名やパスワードを入力することなくアプリが利用できることを確認します。

第10回 デバイスコンプライアンスの構成
https://blogs.vmware.com/vmware-japan/2020/12/dw-windows10mm_10th.html

デバイス順守(デバイスコンプライアンス)を構成し、SAML連携ウェブアプリケーションの利用時にデバイスの順守状態をチェックします。デバイスが非順守状態の場合、SAML連携ウェブアプリの利用ができないことを確認します。

番外編 アプリケーション単位のトンネルを用いた社内リソースへのアクセス
https://blogs.vmware.com/vmware-japan/2020/12/dw-windows10mm_11th.html

アプリケーション単位のトンネル(VMware Workspace ONE Tunnel, Per-App VPN)を構成することで、順守デバイスの指定アプリケーションだけが企業データセンターへ自動接続します。

The post Windows 10モダンマネジメントガイド 連載まとめ appeared first on VMware Japan Blog.

こんにちは。VMware Cloud on AWS 担当している有森です。

パート１に続き今回は VMware Cloud Disaster Recovery を利用するために必要な環境の構成について、その設定の手順を解説します。

VMware Cloud Disaster Recovery の概要については、 Blog「VMware Cloud Disaster Recovery の発表」、構成やアーキテクチャについては、「オンデマンドな災害対策 VMware Cloud Disaster Recovery – パート１ –」もご参照ください。

VMware Cloud Disaster Recovery の環境の構成は以下の流れで作成します。

1. 保護サイトの作成
2. 保護グループの作成
3. DR プランの作成

1．保護サイトの作成

VMware Cloud Disaster Recovery を使って DR 環境を構成するための準備として、 SaaS Orchestrator の管理ダッシュボードで、保護サイトを作成します。

保護サイトの作成は、管理ダッシュボードから３つの工程で進めます。（図1）

• DRaaS Connector をオンプレの保護サイト内に配置する
• DRaaS Connector にオンプレの保護サイト内の vCenter を登録する
• 保護グループを作成する

保護グループは、保護サイトの作成のフェーズでも作成できますが、個別でも作成できるので次の章で説明します。

図1 保護サイトの作成

DRaaS Connectorをオンプレの保護サイト内に配置する

オンプレの保護サイト内に DRaaS Connector を配置します。

表示されているダウンロードのボタンをクリックすると OVA ファイルの URL が示されるので、オンプレの保護サイト内 vCenter 上でその URL を指定して DRaaS Connector を作成します。（図2）

図2 DRaaS Connector ダウンロード

オンプレの vCenter を DRaaS Connector に登録する

オンプレの保護サイト内に展開された DRaaS Connector に SSH で接続して DRaaS Connector の初期設定及びクラウドベース サービスの SaaS Orchestrator を登録します。（図3）これにより、オンプレの保護サイト内の仮想マシンをクラウドベース サービスの Scale-out Cloud File System に保護するための準備が整います。

図3 DRaaS Connector に SSH で接続して初期設定する

2．保護グループを作成する

保護グループとは、保護対象の仮想マシンをシステム単位やアプリケーション種別、重要度などでグループ化したものです。

仮想マシンを指定する場合は、フォルダまたは仮想マシン名のパターンを使用した定義が可能で、最大 500 台の仮想マシンを含めることができます。

また、同時にレプリケーションのスケジュールや保持の設定も併せて行います。保持スケジュールを設定する際には、ランサムウェアの被害者の多くは最初の感染から平均 3 ～ 6 ヶ月後にならないと感染したことに気づかないという調査結果が出ていることに留意してください。

保護グループを削除すると、保護グループで指定していた仮想マシンのスナップショットが全て削除されますのでご注意ください。

3．DR プランの作成

DR プランとは、災害復旧のオペレーションを最小にするために事前に定義するリカバリプランです。保護サイトとリカバリサイトの構成やリソースマッピングなどを定義します。

DR プランの設定で詳細な動作を定義する

保護サイトやリカバリサイト、保護グループの選択、データストアなどのリソースの指定、フォルダやネットワークなどを詳細に指定しておくことで災害発生の際にはリカバリプランを実行するだけで操作が完了します。（図4）オペレーションが定型化され、シンプルになることによって属人化を回避し、ヒューマンエラーを低減することができます。

また、リカバリステップ機能によりリカバリ対象の復元順序を指定することが可能で、リカバリステップと併せて任意のスクリプトの実行も可能です。

図4 DR プランの設定

DR プランと保護サイト、保護グループの関係

DR プランは複数定義可能で、一つの DR プランに複数の保護グループを含めることができます。（図5）

保護サイトには、DR プランで保護する仮想マシンを含む vCenter が含まれます。一台の vCenter は 一つの保護サイトにのみ属し、保護グループ (PG) および DR プランは一台の vCenter にのみ関連付けることができます。

図5 DR プランと保護サイト、保護グループの関係

DR プランの実行は数クリックで完了します。しかしながら、数回のクリックの中にも判断が必要なポイントがあります。それは、どの時点のスナップショットを戻すかです。デフォルトでは最新のスナップショットが選択されていますが、必要に応じてどのスナップショットにするかを選択することも可能です。

DR プランが実行されると、その実行の過程を確認することができます。（図6）

図6 DR プランの実行

まとめ

VMware Cloud Disaster Recovery は、オンプレの保護サイト内への DRaaS Connector の配置とその設定がシンプルであることや DR プランを作成しておくだけで DR の実行も数クリックで実行できることからオペレーションが定型化され、シンプルになることによって属人化を回避し、ヒューマンエラーを低減することができる DR ソリューションです。

次回は、今回ご紹介した DR プランの詳細についてご紹介します。

発表内容のリンク（英語 / 日本語）

• VMware Cloud Disaster Recovery オフィシャルサイト：https://cloud.vmware.com/jp/cloud-disaster-recovery
• YouTube : 「保護サイトの構成」「ヘルスチェック」「リカバリテスト」「フェイルオーバー」

The post オンデマンドな災害対策 VMware Cloud Disaster Recovery – パート２ – appeared first on VMware Japan Blog.

仮想化が進むと、今までの物理の世界で見えていた世界と変わり、物理に紐付かない見えない世界が広がるため、運用やトラブルシューティングのために可視化がますます望まれています。

VMware が考える Virtual Cloud Network のビジョンのなかで vSphere や NSX Data Center で構成されるネットワークに可視化を提供する製品が vRealize Network Insight (vRNI) で、オンプレミスの環境を中心に機能を拡充してきましたが、ニーズに合わせたおおよそ四半期ごとにリリースで、現在はパブリッククラウドやハイブリッドクラウド、また VMware  SD-WAN によるブランチサイトの仮想化も提供しています。

まず、vRNI を使用すると、リアルタイムのトラフィックをマップし、セキュリティ・グループとファイアウォール・ルールをモデル化して、マイクロセグメンテーションのためのセキュリティポリシーをうまく実装するためのネットワークフロー解析により、マイクロセグメンテーションの導入や、パフォーマンスと可用性の向上にも役立ちます。

そして、仮想および物理的なコンピュート、ストレージ、ネットワークのコンポーネントを相関的に見せることで、インフラストラクチャの全体像を把握することもできます。

さらに、これまではインフラの上で動いているワークロード（VM やコンテナ）を重視していましたが、いくつかのワークロードで機能しているアプリケーションの視点も提供するようになりました。

このような機能を提供するために、vSphere や NSX、物理環境、コンテナ環境、VMware SD-WAN、パブリッククラウドに対応し、可視化したい場所をデータソースとして登録します。

簡単なアーキテクチャとしては、プラットフォームとコレクタ（以前の名前はプロキシ）の 2 つのコンポーネントから成り、コレクタがデータソースから構成およびデータを収集、プラットフォームがそれをまとめあげてユーザが情報を取得したり、ブラウザを接続してグラフ等を表示するための接続を提供します。

また、同じアーキテクチャで、プラットフォームをクラウド (SaaS) で提供する、vRealize Network Insight Cloud(vRNI Cloud) がすでに、日本を含めた 4 箇所で、ご利用いただけます。

vRNI と vRNI Cloud は同じアーキテクチャなので、どちらの提供形態が利用しやすいかによってご選択いただけます。

それでは vRNI が 3 つの視点からどのように利用ができるのか、具体的にご紹介していきたいと思います。

ユースケース

ユースケース 1 – アプリケーション

最初は、アプリケーション視点でのユースケースです。

アプリケーションは、基本的に様々な役割を持つサーバがやりとりすることでサービスを提供します。
同じ役割のサーバ（仮想マシンや物理 IP アドレス等）の集合体を、vRNI では階層として定義することができ、階層内、階層間、またアプリケーション間のトラフィックフローを可視化し、分析を提供できます。

例えばシンプルな 3 層アプリケーションの例では、ユーザインターフェースのための Web 層に Web サーバ、ビジネスロジックのための App 層にアプリケーションサーバ、データアクセスのための DB 層にデータベースサーバが存在します。

vRNI はこのようなアプリケーションを、条件をもとに手動で作成、もしくは属性や構成管理データベース (CMDB)、ネットワークフローをもとに自動で検出できます (ネットワークフローによる自動検出は、現在 vRNI Cloud でのみ提供)。

アプリケーションが作成・検出されると、それを見やすい形でまとめ（キュレート）、様々な角度から利用することができます。さらに、VMware HCX とのインテグレーションによって、アプリケーション単位での移行に使ったり、構成管理データベースに情報を提供したり、特定の状況、問題が発生した場合にアラートやイベントを通知します。

では実際にどのような使い方ができるのか、ご紹介していきたいと思います。

モニター: アプリケーションの状況を把握

アプリケーションの構造と通信と可視化できます。
例えば、次のような情報が確認できます。

アプリケーションの概要とトポロジ

• 階層構造
• 構成されている仮想マシン
• 依存するまたは使用する物理 IP アドレス
• 共有サービス
• アプリケーションの通信先アプリケーション
• 関連するイベント

直近 24 時間の最新情報

• 受信または送信トラフィック
• ドロップされたフロー
• 新規および新規で保護されていないメンバー
• アクセスが発生した外部サービス
• インターネットからアクセスされたサービス
• 使用されたアプリケーションのポート

トラフィックフロー (直近 24 時間)

• フロー量に基づくアプリケーション内の上位通信メンバー（仮想マシンまたは IP アドレス）
• ファイアウォールルールが適用された上位のアプリケーションフロー

マイクロセグメンテーション

• 階層のようなエンティティ間のフローについて、すべての許可されたフロー、ドロップされたフロー、保護対象の許可されたフロー、保護対象でないフローなど、様々なタイプのデータ
• 通信の分散状況 (East-West トラフィックの割合や実際のトラフィックなど)

メトリック

• 仮想マシン、または Kubernetes のネットワークトラフィックレート

安全性:  アプリケーションの安全性を確認

NSX によって設定されたマイクロセグメンテーションが想定どおり機能しているのか、ドロップしているのはどんなトラフィックか、最後に任意から任意へのトラフィックを許可するルールが使われていた場合、そのルールを通ったトラフィックがあるのか、あった場合はどんなトラフィックなのか、を確認したり、アプリケーションがやりとりしている国を確認したりすることができます。

移行: アプリケーションを移行する場合の影響範囲を把握

アプリケーションを VMware HCX を使って移行する場合に、アプリケーションのまとまりを HCX の機能の Mobility Group に API/ スクリプトで連携することが可能です。
また、移行前にどれくらいのトラフィック量が流れていて、移行先への移動による通信影響や、アプリケーション内やアプリケーション間の通信を把握することで、移行後の切り戻しのリスクを低減することが可能です。

コンプライアンスチェック:  インフラのPCI-DSSコンプライアンスチェックとレポート

vRNI はこの記事時点の最新の PCI-DSS コンプライアンスチェック機能を提供しており、特定のアプリケーションに対してチェックし、それをレポートとして PDF ファイル（日本語）にエクスポートすることが可能です。

分析: アプリケーション内の上位通信をフローの観点で表示

フローボリューム、トラフィックレート、セッション数、フロー数別に上位通信を表示し、アプリケーション特性の把握に利用できます。

パフォーマンス分析: TCP のラウンドトリップタイムの変化と外れ値の分析

指定した期間のネットワークパフォーマンスの変化を分析し、TCP ラウンドトリップタイムの変化をグラフ表示したり、パフォーマンスに関わる外れ値（異常値）を確認できます。

トラブルシューティング: 問題発生時に原因の特定を援助

アプリケーション内の劣化したフローや、問題が発生しているエンティティを把握し、迅速なトラブルシューティングに役立てていただくことが可能です。下記はその一例です。

このように、以前から vRNI が提供してきた機能に加え、様々な機能や可視化をアプリケーションに対して提供しています。

次回は vRNI の別のユースケースをご紹介したいと思います。

The post vRealize Network Insight – ユースケース 1 appeared first on VMware Japan Blog.

Google Cloud Japan でパートナーエンジニアとしてGoogle Cloud VMware Engine を担当している栃沢です。VMware vExpert としてパートナー様、ユーザ様への VMware vSphere をベースとしたインフラ基盤とGoogle Cloud を組み合わせたソリューションのご紹介、ご提案を日々行っています。

今回から何回かに分けて、Google Cloud VMware Engine について様々な角度からご紹介をしていきます。

ユースケースからアーキテクチャなどパブリッククラウドである Google Cloud VMware Engine と VMware vSphere をベースとしたオンプレミス環境のハイブリッドクラウド利用を念頭に置いて解説をしていければと考えております。

#1 Google Cloud VMware Engine の特長と Google Cloud における位置づけ

#2 Google Cloud VMware Engine での VMware ソリューションの活用

#3 Google Cloud VMware Engine で提供されるコンポーネントとアーキテクチャ

#4 Google Cloud VMware Engine の展開方法

#5 オンプレミス環境とのハイブリッド構成と移行方法

#6 Google Cloud VMware Engine アップデート情報

#7 Google Cloud VMware Engine でのサードパーティ ソリューションの活用

#8 Google Cloud 各種サービスとの連携

連載の過程で新たなアップデートやトピックスなどがあれば、上記の順番の変更や追加などをしながら進めていきたいと思います。

初回となる今回は、Google Cloud VMware Engine の概要についてご紹介をしていきたいと思っています。

なぜ Google Cloud が VMware ソリューションを提供するのか

Google Cloud はエンタープライズの企業、団体に対してさまざまなクラウド サービスを提供しています。

Google Cloud といえば、データ分析、機械学習、AI 領域などのイメージが強いかもしれません。また、Google が提供するさまざまなコンシューマー向けサービスが、それらを支えるインフラストラクチャも自社として保持しています。2020 年 12 月現在、全世界で 24 リージョンを展開しており、各リージョンは Google が独自に保持するバックボーンネットワークで接続しています。

そのインフラストラクチャの上でお客様に対してさまざまなコンピューティング リソースを提供しています。

Google Cloud VMware Engine は、お客様がマルチクラウド、ハイブリッド クラウド環境の構築を検討される際の 1 つの選択肢になり得るのではないかと考えています。

従来ご利用されているオンプレミスの IT サービス基盤、すでにクラウド移行しているアプリケーションも存在する中で、いかに現状の IT 資産を活かしながら新しい価値を想像できる IT インフラストラクチャを提供できるかは重要なポイントになるのではないでしょうか。

Google Cloud VMware Engine とは

ここから、Google Cloud VMware Engine（GCVE と呼ばれています）について簡単にご紹介をしていきたいと思います。

GCVE は、Google Cloud データセンター内に VMware vSphere をベースした Software-Defined Data Center :（SDDC）クラスタを展開して、お客様毎に提供しています。

GCVE は、2019 年に Google が買収した CloudSimple の技術をベースにオンプレミスでご利用されている vSphere による仮想化環境と非常に近い形で展開しています。また、リリースにあたっては VMware と綿密な連携、検証を行った上で VMware Cloud Verified の認定をされたソリューションとしてサービス提供をしています。

GCVE は 2020 年 12 月 14 日時点で全世界 8 リージョンで展開しており、東京リージョンはアジア圏では最初のリージョンとして 9 月に開設しています。

来年にかけても更にリージョンの拡大を順次していく予定です。

ここで GCVE を展開したときに提供されるソリューションをご紹介していきましょう。GCVE を指定した Google Cloud リージョンに展開をすると、検証済のサーバハードウェア（ノード）上に vSphere 仮想化環境の Software-Deifined Data Center（SDDC）がお客様専用に展開（GCVE コンソール上では「プライベート クラウド」と呼ばれたりします。）されます。展開された SDDC 環境は以下の環境がすぐに利用可能な形でデプロイされています。

• VMware vCenter Server Appliance / VMware NSX Manager
• VMware ESXi ホストクラスタ
• VMware vSAN ストレージクラスタ
• VMware NSX-T オーバレイネットワーク (NSX 分散仮想スイッチ）
• VMware NSX-T Edge (Active-Standby) による外部ネットワークアクセス
• VMware HCX

東京リージョンをリリースした 2020 年 9 月時点では、VMware vSphere 6.7u3、VMware NSX-T 2.5.1 で展開しておりましたが、2020 年 12 月より順次 VMware vSphere 7.0u1a、VMware NSX-T 3.0.2 で展開しており、既存ユーザ様についてもアップグレードを進めております。

SDDC が展開されるとお客様は、GCVE 上で稼働させる VM を作成して、必要なセグメント（ネットワーク サブネット）を定義することで、すぐに GCVE 上でワークロードの運用を開始することができます。

展開された SDDC 環境における各 VMware 製品のコンポーネントの監視、パッチ適用、アップグレードなどの基盤運用については、すべて Google Cloud が対応しており、お客様は VMware 製品のコンポーネントに起因する障害に関する対応、日々の運用から開放されます。

そして、オンプレミスの vSphere 仮想化環境から GCVE SDDC 環境、そして、GCVE からオンプレミス環境への仮想マシンの移動については、HCX による vMotion で自由に移行をすることが可能になります。また、HCX により両サイトのネットワーク サブネットを拡張することができる L2 延伸も可能となります。L2 延伸の要件や移行要件などについては、次回以降のブログで詳細を解説していく予定です。

このセクションの最後に、GCVE のスペック、サービスレベルについてご紹介をしておきたいと思います。

展開されるノードのスペックについては以下のとおりです。

ハイパフォーマンスを要求されるアプリケーション、ワークロードにも対応できるハイスペックなハードウェアを採用しています。サーバ仮想化においては、サーバの集約率を高めることは検討の大きなポイントの一つになりますが、GCVE を採用頂くことによりサーバの集約率を向上させて展開するノード数を抑えることで、コストの最適化を目指すことも可能になります。

また、GCVE のノードの展開は、現時点では最低 3 ノードから可能となっており、ノード毎の利用料金については、オンデマンド、及び 1 年または 3 年間の確約利用ベースの課金体系から選択することが可能です。

それぞれの利用料金については Google Cloud VMware Engine 料金ページをご確認下さい。

その他、GCVE のサービスレベル、管理面における内容を以下にまとめておりますので、合わせてご確認を頂ければと思います。

上記以外に、VMware の他のソリューションや VMware vSphere、NSX 環境で幅広く利用されているテクノロジー パートナー様の製品を GCVE 上でも稼働することが可能です。

展開される SDDC の構成、オンプレミス環境との接続構成のベスト プラクティスなど、設計、実装にあたって把握しておいて頂きたいポイントについても、次回以降のブログで詳細を解説していきます。

Google Cloud VMware Engine のユースケースとお客様にとっての価値

ここまでで、Google Cloud VMware Engine が、VMware vSphere をベースとした SDDC 環境をパブリック クラウドとして利用することができるソリューションであることをご理解頂けたのではないかと思います。

GCVE のユースケースは非常に幅広いものとなりますが、その一例をご紹介させていただきます。

• 災害対策（ディザスタ リカバリ） におけるバックアップ サイト
• オンプレミス vSphere 仮想化環境のハイブリッド クラウド拡張
  • データセンター拡張
  • VMware Horizon 仮想デスクトップ環境の拡張
  • 従来の IaaS ではサポートできないアプリケーションへの対応
• インフラ モダナイゼーションと TCO の両立
  • Google Cloud サービスとの連携
  • オンプレミス環境を含めたインフラ モダナイゼーション

災害対策、データセンターの拡張を目指す場合には、単にインフラ基盤だけではなくすでに利用している各種アプリケーションがパブリック クラウド側でも同様に利用できることが重要なポイントとなってきます。

Google Cloud では、VMware はもちろんのこと、各テクノロジー パートナー様とも連携をして GCVE 環境でもオンプレミス環境と同様のソリューションを活用頂けるようにベンダー間のエコシステムも重視しています。

また、GCVE へワークロードを移行することにより、次のステップで Google Cloud の他のサービスをより有効に利用できる環境を整えていくことも可能です。以下の図は Google Cloud のデータウェアハウスのソリューションである BigQuery を活用した事例です。

BigQuery とさまざまな環境に点在するデータソースからデータを集約する Dataflow とを連携することでデータの格納先に関わらずデータの分析を行い、可視化をしていくことが可能となるソリューションですが、オンプレミス環境の VM インスタンスにデータが格納されている場合、VM インスタンスを GCVE 環境に移行することにより、低レイテンシー環境下でのデータ分析を実現することが可能となります。

このように GCVE は vSphere 仮想化環境で培ったスキル、ソリューションを活用しつつパブリック クラウドのメリットを享受できるという側面を持っていると同時に、Google Cloud の他のプロダクトとの連携や、アプリケーションのモダナイゼーションを見据えたクラウド移行の第一歩として活用していくことも可能です。

ぜひ、この機会に今後の IT インフラのモダナイゼーションを目指して、GCVE をご検討頂ければと思います。

次回は、Google Cloud VMware Engine における VMware ソリューションの活用について、VMware と 11 月に共同検証をさせて頂いた内容も踏まえて、ご紹介をしていければと思います。

グーグル・クラウド・ジャパン合同会社
パートナーエンジニア  /  VMware vExpert
栃沢 直樹 (Tochizawa Naoki)

The post Google Cloud VMware Engine 徹底解説 #1 Google Cloud VMware Engine の特長とGoogle Cloud における位置づけ appeared first on VMware Japan Blog.