昨今のサイバーセキュリティの分野では、脆弱性をついた攻撃が多く観測されています。 それらに対応するため各企業様では まずは脆弱性管理をしましょう！といった形で様々な製品を導入されているかと思います。

弊社でも **Tenable** という脆弱性管理をメインとした製品を取り扱っています。管理もまだこれから！というユーザー様やパートナー様がいらっしゃれば是非ご連絡ください！！

ただ、当然ですが、管理だけしてその先はどうするの？という疑問が出てくるかと思います。 管理をして重要度別に対策するのはもちろんですが、各システムで共通の部分は作業なしで対策できるとよいですよね？
そんなご要望にお答えするのが Linux Kernel のライブパッチソリューションの KernelCareになります。

KernelCareとは？

一言でいうと、Linuxカーネルの脆弱性パッチを自動適用する製品です。

大きなメリットは３つあります。

• ダウンタイムの大幅な削減
• 重要なパッチの見逃しが無くなる
• 導入・運用全てでリブートが不要

システムの運用を行っていると、システム側で再起動がどうしても必要なことが多々あるかと思います。
しかし、Kernelに対してのセキュリティ対応はユーザーにサービスを提供する視点からするとユーザーが受けたいサービスとはちょっとずれてきます（決してセキュリティ対応は不要という話ではありません） そして、ユーザーはサービスが止まることは望んでおらず、いつでも使いたいと思っています。

また、脆弱性管理は行っていたとしても複数のOSバージョンやディストリビューションが混在している環境だとそれぞれに対してパッチの適用を行う必要もでてきますし、Kernelの更新時にほかの昨日もアップデートされ、アプリケーションに影響がでないかと気にする必要がでてきます。

KernelCareはメリットにもあるように、既存のシステムに対して簡単にインストール（事前検証は必須です）でき、Kernelの脆弱性について自動でパッチ適用し、既存のアプリケーションにも影響を与えないということを再起動不要で行うことができます。

サポート対象OS

現時点でのサポート対象OSは下記のようなものがあります。

• Amazon Linux
• CentOS / RHEL
• CloudLinux
• Oracle Linux
• Debian Linux
• Ubuntu
• Proxmox ※詳細バージョンはお問い合わせください。

多くのLinuxディストリビューションをサポートしています。

パッチの作成はだれが行う？

Kernelのパッチ作成はKernelCareの開発元である、CloudLinux社が行っています。

パッチはどうやって動いているか？

パッチはメモリ領域に展開されて動作中の Linux カーネルに適用されます。 カーネルアドレススペースにパッチをロードし、実行パスをオリジナルのコードブロックからアップデートされたコードブロックへと安全に切り替えるという仕組みで動いています。

メモリ上で展開しているので、再起動するとパッチは消えてしまいますが、再起動直後にKernelCareエージェントがパッチを取得し適用します。

アプリケーションに影響がないのはなぜ？

パッチが提供するのは脆弱性部分についてのみで、その他のカーネルの機能にはパッチを提供しないためです。 よって、カーネルのバージョンもあがりません。

動作の仕組み

今回投稿しませんが次回以降に大規模やエアギャップな環境に導入する方法についてご案内いたします。

事例は？

そんなクリティカルな製品だと事例を聞きたいですよね。

2019年10月時点で 1700社 46万台の稼働実績があります。 採用企業はハードウェアベンダー、インフラ系事業者、クラウド事業者、ホスティング事業者、などになります。 採用理由はメリット部分が主な理由でセキュア、ダウンタイムなしなどやSOC2準拠などがあります。

まとめ

今回、さらっと製品の説明をしました。 別途製品説明資料が欲しい！といったご要望や脆弱性対応どうしよう？とか古いLinuxがそのまま残ってる・・・などなどLinuxの脆弱性対策をお考えの方はぜひ弊社までご連絡ください。

Webでのお問い合わせはここからになります。

また、次回以降インストール方法など使い方や他製品との連携についても投稿していきますのでよろしくお願いします。

すずきけ

みなさん、こんにちは。すずきです。 前回、KernelCareというKernelの脆弱性に対してLive Patchを当てるソリューションについて投稿しました。
となると次はとりあえず動かしてみよう！ということで、インストールしてみました。

用意した環境

• OS: CentOS 7.5
• HW: VMware VirtualMachine
  • cpu: 4core
  • memory: 8GB
  • disk: 30GB
• Network: インターネット接続が可能な状態

ライセンス

日本の代理店であるGDEPソリューションズ様のWebから申込が可能です。

https://www.gdep-sol.co.jp/form_trial_kernelcare.html

インストールに関連したドキュメント

https://docs.kernelcare.com/jp/installation/
日本語のドキュメントもあります。

インストールしてみる

用意した環境に root アカウントでSSH接続しインストールを開始します。

インストール

インストールは1コマンドの実行で完了します。

curl -s -L https://kernelcare.com/installer | bash

ライセンスの適用

ライセンスは2種類あります。

• Keyベース
• IPベース

トライアルライセンスは Keyベースになりますので下記を実行します。

/usr/bin/kcarectl --register [KEY]

[KEY]の値は別途トライアル申込時に下記のようなメールが届いていますのでKEYの値をご確認ください。

ライセンスの確認

念のため、ライセンスが適用されているか確認します。

kcarectl --license-info

# kcarectl --license-info
Key-based valid license found

パッチの適用確認

KernelCareのパッチは4時間に1回Web上から自動的に取得、適用されます。 まず、適用状態を確認してみます。

kcarectl --info

# kcarectl --info
kpatch-state: patch is applied
kpatch-for: Linux version 3.10.0-862.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Fri Apr 20 16:44:24 UTC 2018 kpatch-build-time: Fri Dec 6 21:42:58 2019
kpatch-description: 27-:1575746834;3.10.0-1062.4.3.el7

管理方法

管理はCLIコマンドが用意されています。

• kcarectl
• kcare-uname

また、KernelCareを導入している端末の適用状況、ステータスについてはKernelCareのクラウドにWebインターフェースを持っています。

• URL: https://cln.cloudlinux.com/console/auth/login

Web管理UIへのログインID、Passwordはトライアル申請時に別途メールにて送付されます。

kcarectl

このコマンドでステータスの確認やオンデマンドでUpdateすることなどができます。詳細については下記のURLをご確認ください。

• https://docs.kernelcare.com/jp/command_line/#kcarectl

kcare-uname

KernelCareで適用した状態のKernelバージョンを見ることができます。シンタックスは unameと同じです。
KernelCareではKernelの脆弱性部分にのみパッチを適用するため、Kernelバージョンは更新されません。KernelCareで保護された状態のKernelのバージョン情報を確認するにはこのコマンドを利用します。

# uname -a
Linux agent4.local 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
# kcare-uname -a
Linux agent4.local 3.10.0-1062.4.3.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

WebUI

WebUIはここからログインします。
KernelCareで保護しているLinuxの一覧や、購入済みのライセンスの情報、期限などが確認できます。

その他

現在のOS Kernelとの互換性の確認

対象のOS KernelにKernelCareが対応しているかも簡単に確認できます。

curl -s -L https://kernelcare.com/checker | python

まとめ

今回はKernelCareのインストール方法を投稿しました。
インストール自体は1コマンドの実行のみで手軽に動作しますし、最低限必要な設定はインストール時に行われています。 驚くほど簡単に動かせますので是非試してみてください。

お問い合わせはここからお願いします。

すずきけ

KernelCareの説明で予告していた大規模orエアギャップ環境でKernelCareを使う場合の投稿です。 KernelCareの仕組み上、Kernelのパッチはどこかからダウンロードする必要があります。ですので、なんらかの方法でダウンロード先（パッチ配信サーバ）を確保する必要があります。
今回説明するePortalはオンプレミス上に作成できるパッチ配信の管理サーバーです。

ePortalの機能

ePortalには以下のような機能があります。

• KernelCareのクラウド上からパッチをダウンロード
• KernelCare Agentのパッチ取得先として指定可能
• Webベースの管理UIを提供

通常のePortalではクラウド上からパッチをダウンロードする必要があるため、完全なエアギャップ（インターネットにはどんな方法でも接続できない）環境では利用ができません。プロキシ経由でなんとか接続する、もしくはお手数ですがお問い合わせをいただければと思います。

ePortalのトライアル方法

Web上でのトライアルの申込ができません。お手数ですが弊社までご連絡ください。

ePortalをインストールして使ってみる

環境

システム要件は下記になります。

https://docs.kernelcare.com/jp/kernelcare_enterprise/

今回は下記のLinuxサーバーを用意しました。

• OS: CentOS 7.5
• HW: VMware Virtual Machine
  
  • CPU: 4core
  • memory: 4GB
  • disk: 200GB (homeディレクトリは作成せず)

プロキシーなしでインターネットに接続できる環境です。

インストール

対象OSに rootでSSH接続した状態で作業をします。

SELinuxの設定変更

今回は検証ですので、SELinuxを Permissiveに変更しています。

vi /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of three two values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

Nginxのリポジトリ設定

ePortalはNginxを利用します。Nginxの取得のためリポジトリを指定します。

cat > /etc/yum.repos.d/nginx.repo < [nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/\$basearch/
gpgcheck=0
enabled=1
EOL

KernelCare ePortalのリポジトリ設定

ePortalのリポジトリを設定します。

cat > /etc/yum.repos.d/kcare-eportal.repo < [kcare-eportal]
name=KernelCare ePortal
baseurl=https://repo.eportal.kernelcare.com/x86_64.el7/
enabled=1
gpgkey=https://repo.cloudlinux.com/kernelcare/RPM-GPG-KEY-KernelCare
gpgcheck=1
EOL

ePortalのインストール

インストールします。

yum install -y kcare-eportal

※画像をクリックしてポップアップウインドウでご覧ください。

ユーザーの作成

ePortalのWebUI管理用に "admin"ユーザーを作成します。
今回は下記のユーザー情報で作成します。

• ユーザー名: admin
• パスワード: password

kc.eportal -a admin -p password

ePortalへアクセス

ePortalのアクセスURLは下記になります。

• http://(ePortal サーバーIPアドレス)/admin

ユーザー名、パスワードは ユーザーの作成で作成したユーザーを使います。

パッチソースへのアクセス設定

KernelCareのパッチ取得先とアクセスする際のユーザー情報を指定します。
ユーザー情報はベンダー（日本は代理店から）個別に提供が行われます。

情報は、Source(URL) , Login , Passwordの3つが提供されます。

• 管理UI -> Settings -> Patch Source

パッチセットのダウンロード

パッチのデータをダウンロードします。Webアクセスの場合はパッチセットのリンクをクリックしダウンロードします。
パッチのダウンロードにはしばらく時間がかかります。

• 管理UI -> Feeds -> Default Feeds

Keyの作成と管理

KeyはKernelCareエージェントを導入後、パッチ取得先（今回はePortal）に接続するためのキー情報になります。
ePortalではePortal上でKeyを発行し、そのキーをKernelCare Agent上で利用する形になります。

• 管理UI -> Keys -> Create タブ

ePortalに接続するKernelCare Agentをインストールする

接続先サーバーを指定してインストールします。
サンプルは下記です。

export KCARE_PATCH_SERVER=http://10.1.10.115/
export KCARE_REGISTRATION_URL=http://10.1.10.115/admin/api/kcare
export KCARE_MAILTO=admin@mycompany.com
curl -s https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash

kcarectl --register demokey1

サーバーのIPアドレス 10.1.10.115は自身のePortalサーバーに置き換えます。 admin@mycompany.comも自身の管理者用メールアドレスに置き換えます。
demokey1はKey情報になります。Keyの作成と管理で作成したKeyを指定します。

動作確認

ePortal

ePortalのWebUI上で管理しているサーバーの一覧や適用されているKernelバージョン（KernelCare適用時のKernelバージョン）を確認することができます。

Agent

コマンドはクラウドを利用した場合と何も変わりません。

kcarectl -iでステータスを確認できます。

また、接続先サーバーの情報などはConfファイルに保存されています。

# cat /etc/sysconfig/kcare/kcare.conf
AUTO_UPDATE = YES
PATCH_SERVER=http://xxx.xxx.xxx.xxx/
REGISTRATION_URL=http://xxx.xxx.xxx.xxx/admin/api/kcare

まとめ

今回はePortalの紹介とインストール・設定方法の基本的な部分と投稿しました。
大量のLinuxに対してKernelCareを適用するにはやはり必要になってくるかと思いますので、大規模環境でKernelCareをご検討される際にはePortalも思い出して頂ければと思います。

お問い合わせはここからお願いします。

すずきけ

こんにちは、ネットワールドの海野です。

今日はNutanix Advent Calendar 2019の最終日ということで、Xi Frame on AHVに関する内容をご紹介いたします。

とはいえ、シンプルが売りのNutanixプロダクトですので、基本的には公式ドキュメントに則って構築を進めていけば問題なく構築ができます。

と書いてしまうと身も蓋もないので、ハマりそうなポイントを含めて構築の流れを紹介してまいります。

Nutanixクラスターは要件を満たしており、必要なバイナリなどはあらかじめダウンロードされていることが前提です。

詳しくはこちらをご覧ください。

1. Prepare your Nutanix Cluster

   ここはドキュメントに記載の通りです。ただし、アカウント名やカテゴリはハードコーディングと思われ、厳密に文字列を判別しますので、TYPOに注意が必要です。

2. Create a Gold Master Image

   注意しなければならない点として、コンソールの接続方式があります。

   PRISMのコンソールではなく、リモートデスクトップで接続するようにしてください。

   画面が見えなくなってしまいます。

   Frame Guest Agentのインストール画面はこのような感じです。

   
   

   
   

   
   

   
   

   Warningとして、Windows Updateを止めろとの記載がありますが、具体的な設定方法はMicrosoftのドキュメントに記載があります。

   GPOまたは直接レジストリで設定する方式になりますが、Xi FrameではADによるGPO適用が若干面倒くさいので、レジストリで適用する方法がいいのでは、と思います。

3. Frame Cloud Connector Appliance Setup

   ネットワークの割り当ては後から変更することはできません！

   十分な注意が必要です。

   また、Cloud Connectorのディスクの使われ方としてブートはISOイメージから、ログはディスクに書き込まれます。

4. Connect your AHV Cluster to Frame

   ここで仮想マシンのインスタンスサイズを定義するプロセスがありますが、後から追加・変更することはできません。

   それを踏まえて、ある程度必要と思われるインスタンスサイズはあらかじめ準備しておく必要があります。

   ちなみに、本筋と離れてしまいますが、このCloud Connectorは CentOS 7がベースとなっています。

   つまり、NTPの設定はChronyで実施する必要がありますのでご注意ください。

5. その他 (Cloud Account登録時のエラーについて)

   Xi FrameのコントロールプレーンにAHVを登録しますが、この画面でエラーになってしまうときがあります。

   
   

   
   

   手順通りにやっていて、ネットワーク的にも問題がなさそうな状況でエラーが発生し、何回か繰り返しても改善されない状況がありました。

   そんなときは、すぐにサポートにてCaseをオープンすることをオススメします。

   上記の状況はユーザー側ではなく、クラウド側に問題が発生していたようで、対応完了の通知以降は正常にCloud Accountが登録できるようになりました。

Nutanix Xi Frame まとめ

ネットワークがフラットなら初めてでも3時間あれば構築できます。

困ったらすぐにCaseをオープンしましょう。

記事担当者 : SI技術本部 海野 航 (うんの わたる)

こんにちは、ネットワールドの海野です。

おかげさまで NVIDIA 様より NVIDI vGPU Community Advisor (NGCA) の認定をいただきました。

NGCA についてはこちらをご覧いただければと思います。

さて、このブログをご覧のみなさまは EUC についてご存知の方も多いと思いますが、今回は NVIDIA の vGPU について、よくいただくご質問を解説してまいります。

• vGPU は何に効果があるの？

  VDI においては、 vGPU が搭載されることにより画面の描画に割いていた CPU リソースを GPU にオフロードすることができ、「 VDI ホスト(物理サーバーのクラスター)の CPU リソースの縮減」と「 VDI 画面転送の高品質化」が期待されます。

  なお、ネットワールドが利用している VDI では以下のようなワークロード(作業)が主に利用され、 GPU マークが付いている項目の CPU 負荷軽減に有効です。

  ※ Lakeside SysTrack にてデータ収集を実施しました。

• ざっくり事務用 VDI の vGPU サイジングはどうすればいいの？

  よくいただくご質問ですが、それを紐解くには NVIDIA のオフィシャルドキュメントを確認し、 vGPU のプロファイルについて知る必要があります。

  ※本来は物理 PC や既存の VDI のアセスメントを実施いただき、それに基づいたサイジングを実施いただく必要がありますが、ここでは説明の簡単化およびプロファイルの概念の理解を目的としたサイジング指針を前提とします。

  2020年3月現在、オフィスユースの VDI には Tesla M10 という GPU がよく利用されますが、このドキュメントには Tesla M10 Virtual GPU Types という項目があり、こちらに詳細が記載されています。

  上記のURLを開くと一覧表がありますが、まずは vGPU の使用目的 (Intended Use Case) を確認します。

  • Virtual Wokstation : CAD などのプロユース VDI
  • Virtuak Desktops : 一般的な仮想デスクトップ ( OA 用途)
  • Virtual Applications : Windows Serverによる公開アプリ (Citrix Virtual Apps や VMware Horizon Apps など)

  ここでは ざっくり事務用 VDI のサイジングですので、 Virtual Desktops を選定します。
  
  これがSTEP1です。

  次にひとつのVDIあたりに割り当てるグラフィックメモリ ( Frame Buffer ) を考えていきますが、ここで注意しなければならないのは Windows 10 では少なくとも 1024 MB 以上のグラフィックメモリの割り当てが推奨されるという指針です。

  2019年12月にリリースされている NVIDIA GRID: Windows 10 vGPU Profile Sizing Guidance の P.10 において、仮想マシン単位のグラフィックメモリの使用量サンプルが記載されていますが、グラフィックメモリの割り当てによって増減はあるものの、M10-1Bのアイドル時でも240MB以上のグラフィックメモリを使用することがわかります。
  これを踏まえますと、 M10-0B のグラフィックメモリ 512MB では Windows 10 を動作させるには心もとない容量であるということが言えます。

  ということで、ここでは最小要件として グラフィックメモリ 1024MB を選定します。
  
  これがSTEP2です。
  
  

  この2点が決まると自動的に M10-1B という Virtual GPU Type に決まります。

  これにより1枚の Tesla M10 あたり、32台の VDI に vGPU を割り当てることが可能です。

• vGPU プロファイルの読み解き方

  さて、この M10-1B というプロファイルですが、他にもいろいろなタイプがあることがお分かりいただけるかと思います。

  例えば、M10-8Q であるとかM10-1Aであるとか…。

  これにはどんな意味があるのかを下図で解説しました。

これからも NVIDIA vGPU についての情報発信をしてまいりますので、よろしくお願いいたします。

記事担当者 : 海野 航 (うんの わたる)

vSphere7.0が諸々リリースされました。

◆ vSphere7.0 (ESXi + vCenter)リリース ノート

https://docs.vmware.com/jp/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html

「本リリースへのアップグレードおよびインストールをサポートしない CPU」でCPUのサポートが明記されています。

vSphere 6.7 のサポート対象プロセッサのうち、次のプロセッサは vSphere 7.0 ではサポートされません。

• Intel ファミリ 6、モデル = 2C (Westmere-EP)
• Intel ファミリ 6、モデル = 2F (Westmere-EX)

インストールまたはアップグレード中に、インストーラによってホスト CPU と vSphere 7.0 の互換性がチェックされます。ホスト ハードウェアに互換性がないと非互換性情報メッセージを示すパープル スクリーンが表示され、vSphere 7.0 インストール プロセスが停止します。

次の CPU は vSphere 7.0 リリースでサポートされていますが、今後の vSphere リリースではサポートされない可能性があります。これを踏まえて、使用するハードウェアを決定してください。

• Intel ファミリ 6、モデル = 2A (Sandy Bridge DT/EN, GA 2011)
• Intel ファミリ 6、モデル = 2D (Sandy Bridge EP, GA 2012)
• Intel ファミリ 6、モデル = 3A (Ivy Bridge DT/EN, GA 2012)
• AMD ファミリ 0x15、モデル = 01 (Bulldozer, GA 2012)

◆ VMware Site Recovery Manager 8.3 リリース ノート

https://docs.vmware.com/en/Site-Recovery-Manager/8.3/rn/srm-releasenotes-8-3.html

◆ VMware vSphere with Kubernetes リリース ノート

https://docs.vmware.com/jp/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-7-vsphere-with-kubernetes-release-notes.html

◆ VMware vSAN 7.0 リリース ノート

https://docs.vmware.com/jp/VMware-vSphere/7.0/rn/vmware-vsan-70-release-notes.html

現状vSphere7.0と互換性があるのは、Horizon 7.1.2、SRM8.3、LogInsight8.0、vRealize Automationくらいで、NSX-v,NSX-T,vReralize Operationsなどは4/6現在サポートが提供されてないので注意が必要です。

https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

vSphere7.0 関連のKB

◆ Important information before upgrading to vSphere 7.0 (78487)

https://kb.vmware.com/s/article/78487?lang=en_US

◆ Update sequence for vSphere 7.0 and its compatible VMware products (78221)

いつもの鉄板のアップデートの順番について

https://kb.vmware.com/s/article/78221?lang=en_US

◆ Enhanced Guest OS information for disks in vSphere 7.0 (78427)

https://kb.vmware.com/s/article/78427?lang=en_US

◆ Third party CIM Providers are unavailable after upgrading to vSphere 7.0 (78136)

32ビットのCIM Providerが非サポートになっているらしいので注意

https://kb.vmware.com/s/article/78136?lang=en_US

◆ vSphere 7 Best Practices (78205)

https://kb.vmware.com/s/article/78205?lang=en_US

◆ Upgrading Load Balanced PSCs 6.x to vCenter Server 7.0 (78446)

https://kb.vmware.com/s/article/78446?lang=en_US

◆ New Kernel options available on ESXi 7.0 (77009)

https://kb.vmware.com/s/article/77009?lang=en_US

◆ Devices deprecated and unsupported in ESXi 7.0 (77304)

https://kb.vmware.com/s/article/77304

というわけで大量のアップデート情報がありますが、vCenter Server 6.5&6.7は、アップデートの提供が2021/11/15まで、サポートの提供が2023/11/15までとなっています。計画的にvSphere 7.0への移行をしていきましょう。

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

こんにちは、ネットワールドの海野です。

今回の記事ではNVIDIAの年次イベントであるGPU Technology Conference (GTC)についてお知らせしてまいります。

NVDIAIはかつて自作ユーザーにとっては Riva 128 などの高品質ビデオチップを共有するメーカーとしておなじみでしたが、

2020年現在ではVDIのためのvGPUの提供や、AI技術をリードしたりニンテンドースイッチの中身(GPU)を提供するなど、

謎の半導体メーカー テクノロジーカンパニーとしてよく知られています。

さて、このNVIDIA GTC 2020、今年は無償のデジタルイベントとして開催されています。

こちらからレジスト(登録)なしでもセッションの一覧を参照することができます。

主にディープラーニングやAIなどのイマドキ感あふれる華々しいセッションが目立ちますが、

もちろんvGPUのセッションもありますので、今回はレジストの方法から注目セッションをご紹介していきます。

vGPUを活用するVDIもここにきて超注目トレンドになってきましたので、ぜひご覧ください！

レジスト方法 (無料!!)

それでは早速GTC2020のレジスト方法を見ていきましょう。

以下のURLからRegistrationのページを開き、[Create Account]をクリックします。

https://reg.rainfocus.com/flow/nvidia/gtcsj20/digitalreg/login

名前やメールアドレスを入力し、[CONTINUE]をクリックします。

ご自身の役職や勤務先の場所の情報などを入力し、[CONTINUE]で先へ進めます。

興味のあるジャンル(ここではVirtualization!!)にチェックを入れ、[CONTINUE]をクリックします。

GTCのWebサイトへの名前掲載可否が確認されますので、お好きな方を選択し、[CONTUNE]をクリック。

特に寄付などをせず、セッションなどを見るだけでは費用は発生しませんので、DIGITAL CONFERENCE PASSにチェックが入っていることを確認し、[SUBMIT ORDER]をクリックします。

サマリ画面で$0.00となっていることを確認し、[CONTINUE]で進めます。

これで無事登録完了です。無料でGTCのセッションを楽しみましょう！

注目セッション！！

残念ながらJensen Huangによるキーノートはキャンセルとなってしまいましたが、

vGPUに関する注目セッションをご紹介します。

1. Enabling Workloads Using High-End Graphics through Windows Virtual Desktop

   いま話題のWVD (Windows Virtual Desktop) について、Azure上でプロユースのワークステーションや高度なナレッジワーカー向けにどのようにデプロイするのがよいのか、
   そのベストプラクティスはどういったものかを解説するセッションです。

2. How NVIDIA Quadro Virtual Workstations, Virtual PCs, and Virtual Apps are Transforming Industries 

   NGCAメンバーであるDane YoungやTony Foster、Sean Massey、Thomas Poppelgaard、 そしてNGCAのモデレーターであるJits Langedijkのセッションです。
   vGPUを搭載したVDIを足掛かりに、DeepLearningやHPCを学んでみたいひとへオススメの内容です。
   (来年は私もここに出たい！笑)

3. Make Decisions with Real Data: How to Properly Size, Benchmark, and Configure a Proof of Concept with NVIDIA vGPU 

   vGPUをどのように導入していくのか、ユーザータイプやベンチマーキングなどのデータに沿ってPoCを進めていく方法を紹介しています。
   比較的初心者向けの内容になっているような気がします。

そんなところで、引き続きGTC2020のvGPUに関するレポートをブログに掲載する予定です。

記事担当者 : 海野 航 (うんの わたる)

皆様こんにちは！

Dell EMCストレージ担当の片山です。 現在も定期的にDell EMCコミュニティのストレージWiki(ブログ)に連載し情報を提供しています！ 今回はUnityVSA(仮想版Unity)のHA構成について検証してみました。

通常UnityVSAはシングルコントローラモデルとしてのみ動作しますが、今回検証したHA構成では物理のUnityと同様にデュアルコントローラモデルの様に動作します。

上図はセットアップ後の画面、HA構成ではきちんとデュアルコントローラとして表示されます。

ただし、HAといっても仮想マシンとして動作するため、同じ1つのESX上に仮想マシン2台を配置してしまうとHAの意味がなくなってしまいます。そのため仮想ホスト側でもHA構成として動作するように設計を考慮する必要があります。

以下の構成例：

確かにストレージの接続構成だけ見ても複雑ではありますね。。。ただ実は構築は簡単なんです！

続きはDell EMCコミュニティのストレージWiki(ブログ)に連載していますので是非ご覧ください！

＜[UnityVSA] HA(Dual-SP)を構築、検証してみた！(1)＞

＜[UnityVSA] HA(Dual-SP)を構築、検証してみた！(2)＞

その他、Networld Techのブログ一覧はこちら！​ https://www.dell.com/community/ストレージ-Wiki/tkb-p/storage-wiki-jp/label-name/EvalReport

こんにちは、ネットワールドの海野です。

今回は Veeam Backup & Replication のパフォーマンスに関する記事をお届けします。

バックアップで気になる点といえば、バックアップの取得やリストアに必要な時間が⼤きなポイントですが、VBR v10 のバックアップパフォーマンスが v9.5u4b と⽐べてどうなっているのかという内容をまとめてみました。

なお、今回の内容はあくまで弊社環境での結果をお伝えするという主旨であり、何らかのサイジング指針や、パフォーマンスの保証をするものではございませんので、ご注意をお願いいたします。

また、後述するように今回の内容はお客様のトレーニングのための Nested ESXi 環境によるものであり、正しいサイジング指針に従った場合のパフォーマンスではありませんので、重ねてご注意をお願いいたします。

従いまして、ここで示す所要時間やパフォーマンスは本番環境に適用されるものではありません。

以下、記事のアジェンダです。

• ソフトウェアの性能・使⽤感
• 注目!! VBR v10 対 v9.5u4b
• ⽐較に利⽤した環境 : ネットワールドのハンズオントレーニングラボを利⽤して
• ⽐較項⽬その1 : Active Directory
• ⽐較項⽬その2 : SQL Server
• その他の⽐較項⽬
• 結果のまとめ
• お知らせ

ソフトウェアの性能・使⽤感

私たちは仕事などで Windows 10 をインストールしたパソコンを使いますが、みなさまもご存知のとおり Windows 10 では Windows Update を重ねるごとに「動作が重くなっちゃった…」など使⽤感に変化が現れることが⼀般的です。

私⾃⾝は Citrix などの EUC 分野を得意としており、お客さまへ VDI の使⽤感などのアドバイスをすることもありますが、残念ながら上述のとおり機能追加や不具合修正、そしてセキュリティ強化の影響によりアップデートするごとにパフォーマンスが低下していくことは否定できません。

具体的な例として、VDI ベンチマークである LoginVSI を利⽤して VSImax (快適に VDI が利⽤できる上限数)を⽐較すると、まったくアップデートをしていない Windows 7 が⾮常に⾼い成績を出していることが分かります。

※注釈 : 下図は当時最新の Windows Update を適⽤した Windows 7 のLoginVSIによるVSImax の値を100%としたときの相対値で、数値(%)が⾼いほどよい性能を⽰します。

※出典 : GO-EUC - Windows 7 vs Windows 10 VDI Performance Test

注目!! VBR v10 対 v9.5u4b

皆様こんにちわ。　ネットワールドストレージ担当です。

今回紹介するのは本日日本で発表された新しいMidRangeストレージ！

そう！PowerStoreです！！！

今回は製品概要や初期構築にあたる部分を紹介していこうと思います。
新製品のPowerStoreのβテストを我々で実施しておりましたので、
このような記事にて皆様知っていただきたいと思っております！

まずPowerStoreには大きく分けて2つシリーズがあります。
それがPowerStoreTとPowerStoreXになります。

PowerStoreTはUnityなどと同様にSAN、NAS、vVolを扱うことが出来ます！

PowerStoreXはSAN、vVolを扱うことができるのはTモデルと同様ですが、それに加えてESXを扱えます！
構築時にいろいろと条件はありますが今までにないモデルと言えるのではないでしょうか。

PowerStoreにはモデルが5つ用意されており、1000、3000、5000、7000、9000というものになっています。
主な違いはCPUとメモリーでCPUは4x8c～4x28c のSkylakeとなり、メモリーは384GB～2560GBとなっています。

Diskはそれぞれ約100本搭載できますが、DPEの末尾2本or4本がNVMe NVRAM用となっているようです。

その他細かな仕様については以下のようなドキュメントを参照いただけると幸いです。
・PowerStoreTシリーズ
https://www.delltechnologies.com/ja-jp/storage/powerstore-storage-appliance/powerstore-t-series.htm
・PowerStoreXシリーズ
https://www.delltechnologies.com/ja-jp/storage/powerstore-storage-appliance/powerstore-x-series.htm

長々と言葉を書いててもつまらないので、ここから実際の初期構築までの紹介をしようと思います。
まず、構築の事前準備をしていただきたいのが、

・IPアドレス（Tモデルは5つ、Xモデルは7つ）・・ちょっと多いですね。
・DNSサーバ
・NTPサーバ
・作業用端末
・ネットワークスイッチ

今回は弊社で構築してみた環境の図を載せてみます。
※スイッチが大量にあるのは他の環境との兼ね合いなので、実際には必要なポート数があれば1つで充分です。

あらかじめネットワーク構成を全て整えてもらえたら準備完了です。

セットアップ用のツールを起動して、筐体が認識することを確認してください。
今回はPowerStoreTモデルでの画面になります
※以下UIが実機と異なる場合があります。

169.254.XXX.XXXのIPアドレスでブラウザアクセスするとPowerStore Managerが起動します。
ウィザードに従って情報を入力していき、先へ進んでください。

IPアドレス入力の部分については事前準備で決めたIPをそれぞれ入力していきます。

そしてすべての入力が終わったら構成の検証を実施していきます。
ここでネットワークのチェックやその他いろいろなチェックをしているので、エラーが出ている場合は
その部分の設定を見直して再度検証するという流れになります。

全てのチェックが通ったら構築を実施しましょう！！
構築時間はだいたい60分程度で完了します。

ユーザー名にadmin、パスワードは設定したものを入力するとログイン完了となります！

今回は新MidRangeストレージ PowerStoreの概要～構築をお届けしました。
次回は画面UIなどを紹介していければと思います。こうご期待ください。

その他、Networld Techのブログ一覧はこちら！?

https://www.dell.com/community/ストレージ-Wiki/tkb-p/storage-wiki-jp/label-name/EvalReport

皆様こんにちわ。ネットワールドストレージ担当武田です。

今回も前回に引き続き新製品PowerStoreをご紹介します！！

前回は主に製品の概要や初期構築のご紹介だったので、今回は実際のGUI画面からTモデルとXモデルの違いなどを見ていこうと思います。

まず、こちらがログイン後のTop画面です。緑枠で囲ってある箇所がサービス系の設定で使うタブとなっており、ボリュームの作成やレプリケーションの設定などを行います。

Migrationもこちらから行います。

Migration機能は個人的にPowerStoreの推しポイントの一つなのでまた次回詳しくご紹介させて頂きます。

赤枠で囲っているSettingsからはクラスターのシャットダウンやバージョンアップなどの管理系の設定やオペレーションを行う際に使います。

Unityとは文言が異なっていることなどがあるため、初めは操作のしづらさを感じるかもしれませんが、少し触れば直感的に操作できるようになるかと思います。

ここからはTモデルとXモデルの違いについて見ていきましょう。

まずはプロトコルによる違いです。現在はNASサービスはTモデルで提供されております。

そのためStorageタブに出てくる内容に違いがあります。

File SystemsとNAS Serversの項目がTモデルにのみあることが確認できるかと思います。

現在、NAS Serverの作成などの操作はTモデルでのみ実行可能です。

こちらは管理系のIPの数の違いです。

各モデルともCluster用の管理IPアドレスやNodeのCoreOSのIPアドレスがあるのは共通ですが、XモデルにはESXiが存在するためHost Nodeの項目にESXiのIPアドレスがあることがわかります。

実際にESXiにアクセスし操作をすることも可能となっております。

続いて、こちらは利用する管理ポートの違いです。

TモデルはUnityでもおなじみのManagementPortを利用しますが、XモデルではManagementPortの利用はありません。サービス用のポートを使って管理系の通信を行っております。

他にも細かい点を含めれば違いはまだまだありますが、今回はここまでのご紹介と致します。

このように各モデルでユースケースが異なるので、目的に合ったモデルを選定することが出来るのがPowerStoreの大きな特徴となっています！

今回は新MidRangeストレージ PowerStoreを触ってみよう ～GUI画面紹介編～ をお届けしました。

次回は弊社内で行った検証内容の一部をご紹介できればと思います。

最後まで読んでいただきありがとうございました！

その他、Networld Techのブログ一覧はこちら！

https://www.dell.com/community/ストレージ-Wiki/tkb-p/storage-wiki-jp/label-name/EvalReport

こんにちは、ネットワールドの市川です。

今回は Veeam Backup & Replication のVMware vSphere 7 サポート開始に関する記事をお届けします。VMware vSphere 7 が、4月9日にリリースされ、バックアップメーカー各社の対応が始まっております。この度、Veeamもついに、Cumulative Patch 2 で、vSphere 7 のサポートが開始されました。

Veeam社 KB

KB3161: Veeam Backup & Replication 10 Cumulative Patch 2

https://www.veeam.com/kb3161

今回は、早速Veeam Backup & Replication V10を使用して、vSphere 7 環境のバックアップを検証しました。基本的なバックアップ、リストアに加え、SQLのエージェントレスバックアップ、アプリケーションアイテムのリストアも検証しております。

また、7/17(金)にクラウドバックアップWebセミナーを実施いたしますので、それに向けて、検証項目 4では、AWS S3へのコピーのクラウド連携も検証しております。まとめ部分でWebセミナーについてご案内しますので、是非ご参加ください。アジェンダはこちらです。

• 構成のご紹介
• 検証項目 1：仮想マシン(Windows/Linux) バックアップ
• 検証項目 2：ファイルレベルリストア(Windows/Linux)
• 検証項目 3：仮想マシンのフルリストア(Windows)
• 検証項目 4：SQL バックアップ (AWS S3 へコピー)
• 検証項目 5：アプリケーションアイテム(DB)のリストア
• まとめ

構成のご紹介

今回の検証に使用した構成図は、下記の通りです。

前回の記事の「VBR v10 で気になるバックアップのパフォーマンス変化 (Veeam)」の構成で、VCSA及び、ESXiが7になった環境です。

こちらの環境のバックアップサーバに、Cumulative Patch 2が含まれたISOイメージを使用し、新たにVeeamをインストールし実施しています。今回も前回と同様に、Nested (*1) になっている関係上、実機と⽐較して少々遅く感じるものの機能検証などにはまったく問題ありません。

*1 : VMware ESXi の上にさらに VMware ESXi を構築して、⼊れ⼦状態になっていることを⽰します。

検証項目1：仮想マシンのバックアップ

VM01-Winと、VM02-Linux という名前の仮想マシンをローカルのRepositoryにバックアップします。

こちらは問題なく、バックアップが完了しました。

検証項目2：ファイルレベルのリストア(Windows/Linux)

続いて、ファイルレベルのリストア(FLR)です。

まずは、VM01-Winのテスト用ファイルを削除します。

その後、Veeam Explorerを使用し、FLRを実行しました。

無事にリストアが成功しました。WindowsのFLRは問題ないようですね。では続いて、Linux のファイルレベルリストアを確認していきます。LinuxのFLRはWindowsと異なり、ヘルパーアプライアンスが、ESXi上に作成されるので、そこも合わせて確認していきたいと思います。

まずは、先程と同様に、VM02-Linuxのテストファイルを削除します。

そして、ヘルパーアプライアンスの設定をして実行すると、

ヘルパーアプライアンス、Veeam Explorerの起動を確認できました。VeeamExplorerから、先程削除したテストファイルをリストアします。

Linuxのファイルリストアも無事に成功しました。

検証項目 3：仮想マシンのフルリストア(Windows)

続いて、先程バックアップした、VM01-Winのフルリストアを検証しました。

成功しました。フルリストアも問題なく、リストアが出来ました。

検証項目 4：SQLバックアップ (AWS S3へコピー)

続いて、Veeamの推しであるアプリケーションのエージェントレスバックアップの検証を実施しました。

ここで、バックアップ保存先をローカルだけでなく、SOBR(*2)を構築して、AWS S3のコピーも実行してみましょう。

今回は図のように、内蔵Diskと Amazon S3で、SOBR(*2)を作成しております。こちらをバックアップ保存先として、バックアップを実行していきます。

*2：Scale-Out Backup Repositoryの略称で、 Repositoryをプール化する機能です。ローカルとObject Storage でSOBRを構築することで、クラウドへバックアップデータのコピーや古くなったデータの移動を実施することができます。

まず、「SQL01」というジョブのオンプレへのバックアップが成功しました。その後、「SQL01 Offload」というジョブが自動的に実行され、AWS S3へのコピーも成功しました。

※SQL01 Offloadで、NAME欄が、「SQL01 SQL01」 となっていますがこちらは、バックアップジョブ名「SQL01」、仮想マシン名「SQL01」という表記となっています。

検証項目 5：アプリケーションアイテムレベルのリストア

続いて、アプリケーションアイテムレベルのリストアを検証します。「HandsOnDB」というテスト用データベースを削除します。

その後、Veeam Explorerを使用し、「HandsOnDB」をデータベース単位でリストアします。

リストアの成功を確認できました。

まとめ

以上の検証結果から、vSphere 7 環境でも問題なく、Veeamの機能が使用できることが確認できました。VMware vSphereのバージョンがあがることで、バックアップ品質テストを入念に行っていると聞いていますので、vSphere 7 環境でも、安心してVeeamを使って頂ければと思います。

最後に、7/17(金)バックアップベンダー8社を集めたクラウドバックアップWebセミナーを実施いたします。クラウドにおけるバックアップ製品のメリット・デメリットについて、バックアップベンダー全8社が徹底討論します。

是非下記のURLからお申し込みください。

【Webセミナー】クラウドバックアップどうするの？メーカー8社がベストプラクティス徹底討論

https://networld.smartseminar.jp/public/seminar/view/2971

こんにちは。

Data Domainも今回で第十八回目となりました。
第十七回目ではDD3300の初期設定の流れについて見てきました。
現在、DDOSの最新バージョンはDDOS7.2（7.2.0.5-653470）になります。

今回はアップグレードを実施する際の考慮事項についてご紹介します。

　DDOSのアップグレードについて見ていきましょう。


◆ DDOSアップグレード
-------------------------------------------------
・DDOSのアップグレードは原則2リリース・ファミリーまでとなります。
　
・事前にRelease-Noteを確認し、アップグレードの可否を
　確認しましょう。

　次にアップグレード時の

　　作業前・作業時の考慮事項を見てみましょう。

◆ 作業前の考慮事項
------------------------------------------------
・アップグレードするバージョンがDDシステムに　
　対応していることを確認。

・DDシステムの対応はRelease-Notesに記載しています。

・レプリケーション互換性の場合、レプリケーションの互換性を
　事前に確認。

※DDOS7.2に対応しているのは以下のDDシステムです。　

・DD3300,

・DD4200, DD4500,

・DD6300, DD6800, DD6900,

・DD7200,

・DD9300, DD9400, DD9500, DD9800, and DD9900

◆ 作業時の考慮事項
------------------------------------------------
・アップグレードは書き込み・データ転送が発生していない　
　時間に実施。

・レプリケーション構成の場合、慣例的に送信先から
　アップグレードを実施。

・双方向レプリケーション構成の場合、どちらからでも
　アップフレードを実施しても問題ありません。

・アップグレード時にレプリケーション手動操作（停止・開始）は
　不要。アップグレード後に自動的に転送が再開されます。

・アップグレード時間はおおよそ ”約1時間程度”になります。
　ES30(拡張エンクロージャ）の数等により、それ以上の結果になる
　傾向があります。

　次にレプリケーションの互換性を見てみましょう。

◆ レプリケーション互換性
---------------------------------------------------

レプリケーション構成で既存環境のDDOSをアップグレードする際、
異なるDDOS間のレプリケーションの互換性を考慮する必要があります。

・レプリケーション互換性は原則2リリース・ファミリーまで

　となります。

・レプリケーション互換性はAdministration Guideに

　記載されています。

・Administration Guide内の

　Replication version compatibilityを確認

＜DDOS7.2 Administration Guide P.338より抜粋＞

次回は別の機能、技術的な部分についてご紹介したいと思います。
それでは次回もよろしくお願いします。

担当：Data Domain製品担当

こんにちは。

Data Domainも今回で第十九回目となりました。
第十八回目ではDDOSアップグレード時の考慮事項について見てきました。
今回はCLIを利用してのシステム情報の出力についてご紹介します。


　CLIを利用したシステム情報の出力について見ていきましょう。


◆ auto support show report
------------------------------------------------------------------------------------
Data Domain構築後、設定した内容確認を行う時があるかと
思います。autuo support show reportを利用することで
システムに関する情報を出力することが出来ます。


◆ 出力結果をログに保存
------------------------------------------------------------------------------------
TeraTerm等のターミナルソフトでSSHでData Domainに接続し、
ログの出力設定をして、CLIを実行します。

Data Domainにシリアルケーブルで接続してシステム情報を
出力することも出来ますが、IP接続のSSHと比較すると
出力は遅いです。

このCLIは構築作業時のエビデンス・設定情報の見直しで
活用できます。


　auto support show reportの出力内容を見ていきましょう。


◆  出力内容
------------------------------------------------------------------------------------
出力結果は各項目ごとに情報が出力されます。
出力された情報をもとにシステム情報を確認が出来ます。

出力結果の一部ですが、主に以下の内容が出力されます。


【GENARAL INFO】
・DDOSバージョン
・シリアルナンバー
・モデル


【Net Show Hardware】
・搭載イーサネットの論理ポート名
・搭載イーサネットのハードウェアアドレス


【SOFTWARE CONFIGURATION】
・システムに適用されているライセンス情報


【Net Show Settings】
・構成しているネットワーク情報
・IPアドレス、仮想NIC、冗長化構成


【Disk Show Hardware】
・搭載ディスクのディスク番号・搭載スロット
・搭載ディスクの容量
・搭載ディスクのシリアル番号
・搭載ディスクタイプ（SAS）


【IPMI Show Hardware】
・IPMI Firmware Revision
・IPMI Version
・IPMIユーザー情報


【MTree List】
・構成したMTreeの一覧


【Net Route Show Tables】
・構成したルートテーブル情報


【DDBOOST INFORMATION】
・DDBOOSTステータス
・構成したStorage Unit情報


【VTL Configuration】
・構成した仮想テープライブラリ情報
・ライブライ名
・ドライブ
・Slot/CAPS


【VTL Groups Configuration】
・構成したアクセスグループ情報
・アクセスグループに所属するイニシエータ情報
・アクセスグループに所属する仮想テープライブラリ
・仮想テープライブリが利用するエンドポイント


【VTL Pool Summary】
・構成したPoolの一覧
・Poolに格納しているテープ本数
・Poolに格納しているテープサイズ（総容量）


【CIFS Shares】
・構成したCIFSの一覧


【NFS Export Show Detailed-Stats】
・構成したExport NFS情報
・NFSクライント


【NFS Status】
・システムて有効になっているNFS Server Virsion



次回は別の機能、技術的な部分についてご紹介したいと思います。
それでは次回もよろしくお願いします。


担当：Data Domain製品担当

皆様こんにちわ。ネットワールドストレージ担当小野と武田です。

PowerStore第3弾となる今回は前回の投稿でちょっとだけ紹介した、Migrationとバージョンアップについて簡単に紹介していきたいと思います。

まず最初に今回の目玉機能と思っているMigrationからとなります。

主にPowerStoreに対してMigrationできる筐体は・・・・

・VNX2(05.33.009.3.544以降)
・Unity(5.0.0.1.3.060以降)
・SC series(07.04.02.34以降)
・PS series(10.0.3以降)

となっています。

Windows、Linux、ESXiと3種類の移行方法がありますが、それぞれサポートされているものが異なります。
今回はLinuxのみサポートされているUnityからのデータ移行をやってみたので、その紹介となります。
※事前にLinuxマシンにAgentを導入する必要があります

まず最初に移行元となるストレージを追加します。

次に移行対象となるVolumeを選びます。

Volume選択が完了したら、Agentを導入しているホストを選択します

全ての設定が完了したら、データ移行開始となります。

データコピー中はステータスが「In Progress」となりますが、いったん完了すると「Ready For Cutover」となります。

Cutoverが完了すると「Import Completed」となり、移行元ストレージ側はホストからLUNがアンマウントされ、PowerStore側のみにマウントされた状態となります。

これでホスト側は意識することなくストレージを変えることが出来ます！！

続いてはバージョンアップの説明をいたします。

バージョンアップ作業は、今後ユーザー様でご実施頂くことを想定しているとのことですので、簡単に流れをご紹介出来ればと思います。

なお、Xモデル/Tモデルいずれも操作はほとんど変わらないので、Xモデルでの操作と致します。

まず初めに機器へGUIログイン後に"Setting"タブから"Upgrade"を選択致します。

こちらの画面からは現在のバージョン情報の確認が可能で<1.0.0.0.4.032>であることがわかります。"UPLOAD PACKAGE"を選択するとサポートサイトからダウンロードした新しいバージョンのイメージファイルをローカルからアップロードすることが出来ます。

アップロードが済んだら、対象のファイルにチェックを入れて"HEALTH CHECK"を実行します。

画面下部の"Recent activities"からヘルスチェックの実行結果が確認できます。

"Completed"ステータスが確認出来ましたのでそのまま"UPGRADE"を実行します。

実行中はバックグラウンドでジョブが動き始めます。ローリングアップグレードとなっており片側ノードずつ落ちていくため、サービスの全断は発生しない仕組みとなっております。

"Recent activities"のOperation名の箇所をクリックすれば、アップグレードジョブの進行状況が確認できます。

本環境における検証ではおよそ36分ほどで完了しました。

アップグレード後のバージョンを確認すると、<1.0.0.0.4.038>になっているのがわかるかと思います。

以上で、バージョンアップは完了となります。

GUIでのオペレーションのみとなるため非常に簡単で特につまることなく実行出来ました。

最後まで読んでいただきありがとうございました。

3回にわたり新製品PowerStoreのご紹介をさせて頂きましたが、一旦はこれで最後と致します。

また、新たなアップデート情報など出てきましたら、随時ご案内させて頂きたいと思います。

Networld Techのブログ一覧はこちら！

https://www.dell.com/community/ストレージ-Wiki/tkb-p/storage-wiki-jp/label-name/EvalReport

皆様こんにちは！

Dell EMC 製品 HCI/ストレージ/バックアップを西日本で担当している河田と申します。

現在も定期的にDell EMCコミュニティのストレージWiki(ブログ)に連載し情報を提供しています！
今回は前回のAvamar Virtual Editionの構築から更にNASのバックアップコンポーネントとなるNDMPについて検証してみました。

もちろん、仮想（Virtual）アクセラレータとして構成しますので、簡単に試すことが可能です。では、早速始めてみましょう

以上で、下ごしらえは完了です。いかがでしょうか？

実際にAvamar Virtual NDMP Accelerator をインストール、Avamarへ登録する手順については

下記DELLコミュニティのBlog投稿で公開しておりますので、是非ご確認してください。

最後まで読んでいただきありがとうございました！

Networld Techのブログ一覧はこちら！

​https://www.dell.com/community/ストレージ-Wiki/tkb-p/storage-wiki-jp/label-name/EvalReport

みなさん、こんにちは、ネットワールド　宮城直也です。

このシリーズでは、vRealize Operations Manager（以下、vROps）の製品概要、ユースケースに基づいた利用方法、最新版のv8.1アップデート情報など記載します。みなさんのvROpsの知見を深めていただき、今後のご提案・導入の参考になればと思います。

vRealize Operations Managerとは

vROpsは、一言で説明すると、「物理/仮想/クラウド インフラストラクチャを問わずアプリケーションからストレージに至るまでを可視化し、インテリジェントな運用管理を実現」するソリューションです。

vRealize Operations Manager クイックスタート

vRopsの大きな特徴として以下の4点が挙げられます。

1. vSphereなどの監視対象からリソース情報を収集・長期蓄積・分析を実行
2. 動的しきい値など独自の基準で異常を検知し、専用のダッシュボードから原因調査が可能
3. サードパーティ製の管理パックを追加することで、サーバー、ストレージ、スイッチなどの物理インフラ、パブリッククラウドなどユーザーのインフラをまるごと管理可能
4. カスタムダッシュボード、カスタムアラートなどユーザー環境に沿った柔軟なカスタマイズ性

１．リソース情報の取得・蓄積・分析と最適なリソース運用

vROpsはvSphereなどの監視対象から、デフォルトで5分（最短1分）おきにデータを収集し、内部データベースに最大120か月蓄積します。

vRealize Operations Managerのデータ収集イメージ

vROpsはこのように収集したデータを分析し、ESXiホストのCPU/メモリ使用量などリソースを予測したり、リソース使用状況に応じた仮想マシンの過剰なリソース割り当てを検知したりすることが可能です。

ESXiホストのリソース予測

再利用可能な仮想マシン一覧

また、仮想サーバーの追加などシナリオを作成し、現環境にどの程度影響があるのか計算することができます。パブリッククラウドを導入しているユーザー様には、パブリッククラウドに移行した場合の費用も計算することが可能です。

パブリッククラウド利用時のコスト

2.動的しきい値など独自の基準で異常を検知し、専用のダッシュボードから原因調査が可能

vROpsには vCenter Serverとは異なる独自の検知機能が備わっています。vROpsでは、データを長期的に保存することが可能なため、過去のデータに基づいて、仮想マシンやホストの一時的な負荷が周期的な動作なのか、異常な動作なのか判断することが可能です。

メモリ使用率の動的しきい値（グレー部分がしきい値範囲）

「VMのトラブルシューティング」ダッシュボードでは、仮想マシンのリソースの使用量や他仮想マシンとのリソース競合などに加え、アクティブアラート、ディスクが保存されているストレージ、稼働しているホストのステータスなどを一つの画面で表示します。

VMのトラブルシューティング

また、ダッシュボードから仮想マシンや、ホストをクリックすると、リソースの使用状況や発生しているアラートを一覧にしたダッシュボードが表示されます。

ホストの専用ダッシュボード

この画面では様々なタブが用意されており、【環境】タブではどのホストでどの仮想マシンが動いているかストレージは何を使っているかなどオブジェクト同士の相関図が表示されます。ある仮想マシンでCPUの高負荷が発生した場合、このダッシュボードからホストへの影響、およびホスト配下の仮想マシンへの影響を瞬時に確認することができます。

ホストと他オブジェクトの相関図

3.サードパーティとの連携

vROpsはパブリッククラウドと連携し、現在の利用状況やオンプレ環境の移行計画を練ることもできます。また、サードパーティから提供されている管理パックを追加することで、物理サーバー、ストレージ、スイッチなどのハードウェア機器の監視が可能になります。

AWSとの連携

4.vROpsのカスタマイズ

vROpsには標準でvCenterとは異なる独自のダッシュボードやアラート機能が備わっていますが、ユーザー様の運用に合わせてこれらを自由にカスタマイズすることができます。

運用を続けるにつれ使用頻度の高いダッシュボードと、そうではないダッシュボードに分かれることは多々ありますので、これらをひとまとめにしてホーム画面にまとめることができます。

アラートに関しては、特定の仮想マシンがダウンした場合に発報するなど独自のアラートを作成することができます。

ダッシュボードのカスタマイズ画面

いかがでしたでしょうか。

vCenter Serverとよく比較されることが多いのですが、vCenter Serverがもつ運用・監視機能をさらに拡張したソリューションであることをご理解いただけるかと思います。

次回はvROpsの具体的なユースケースについてご紹介していく予定です。

では、次回をお楽しみに。

製品公式ドキュメント

https://docs.vmware.com/jp/vRealize-Operations-Manager/index.html