スキップしてメイン コンテンツに移動

vSphere Memory Tieringで物理RAM容量の限界突破

 

VCFをなんとか自宅で動かせないかとアレコレ考えていたところ、RAM容量のハードルを越えることができる可能性のある機能を見つけたので試してみることにしました。

色々調べてみると、物理RAM容量96GBのミニPCでHolodeckを動かすためにこの機能を使っているような強者も居るようなので、手元にあるミニPCで試してみます。


大まかな流れは以下の通りです。
    1．ESXiにてMomory Tieringの有効化
    2．RAMとNVMeメモリの比率変更
    3．NVMeメモリ使用量の確認


1．ESXiにてMomory Tieringの有効化

まずは、ESXiの管理コンソールにログインし、実行前のメモリ容量を確認しておきます。このサーバーには物理RAMを64GB積んでいるので、容量もその通り出ています。


対象のESXiにSSHでログインして以下のコマンドを実行し、MemoryTieringを有効化します。
esxcli system settings kernel set -s MemoryTiering -v TRUE


次に、以下のコマンドを実行して、特定のディスクをtierdeviceに変換します。
esxcli system tierdevice create -d /vmfs/devices/disks/[Disk Name]
例として以下のようなイメージです。


実行後、以下のコマンドでデバイスが表示されればOKです。
esxcli system tierdevice list


再起動後、ESXiのWeb管理コンソールログインしてメモリを確認すると、メモリの容量が増加(64GB→80GB)していることが確認できます。
デフォルトでは物理RAM容量の1/4のサイズがTiered Memoryとして追加されるようです。




2．RAMとNVMeメモリの比率変更

デフォルトではRAMとNVMeメモリの比率は4:1になります。
つまり、64GBのRAMでMemory Tieringを有効化すると、デフォルトではNVMeのメモリは16GBにしかなりません。
この比率は設定で調整ができるため、今回は最大まで増やしてみます。
一応RAM容量を超えないようにすることが推奨されています。
が、ラボ環境なので気にせずMAXに設定してみます。笑

ESXiのWeb管理コンソールにログインし、「ホスト>管理>システム>詳細設定」に移動し、検索欄で「Mem.TierNvmePct」を検索します。
表示されたキーを選択して「オプションの編集」をクリックします。
【補足】最大値は「400」、つまりRAM容量の4倍が上限になります。


最大値である「400」を設定して「保存」をクリックします。


再起動後、再度ESXiホストのメモリ容量を確認すると、約320GBほどまで増えています。
RAM:NVMeの比率が1:4(64GB:256GB)になっています。



3．NVMeメモリ使用量の確認

物理RAM容量を超えるサイズのメモリを割り当てた仮想マシンを作成します。
物理RAMは64GBでTiered Memoryを含めると320GBほどなので、200GBのメモリを持つ仮想マシンを作成してみます。


仮想マシンを作成してOSをインストールし、OSにログインしただけの状態でESXiにSSHでログインし、以下のコマンドでESXiのメモリスタッツを取得してみます。まだtier1の方は使用されていません。
memstats -r vmtier-stats -u mb -s name:memSize:active:tier0Consumed:tier1Consumed


メモリ負荷ツール(TestLimit)を使用して意図的にメモリを大量に消費してみます。


その状態でもう一度ESXiのメモリスタッツを確認すると、Tier1メモリが少し消費されていることが分かります。
テストツールだからか、ツール内で指定した値そのままの数値は出ませんでしたが、物理RAM容量である64GBを少なくとも30GBほど超過してメモリ容量を消費していることが見て取れます。


いつかHoloDeckのデプロイにもチャレンジしてみたいと思います。（手元にある機器はメモリ以外のハードウェアもあまり潤沢ではないので動くかどうかは...笑）


コメント

コメントを投稿

このブログの人気の投稿

Workspace ONE Accessに証明書認証でログイン

Workspace ONE AccessではSaaSなどのサービスへのアクセス管理ができますが、クライアント証明書認証の機能も備わっています。 ここでは、Workspace ONE UEMから配信した証明書を使用して、Workspace ONE Accessに証明書認証でログインする、ということをやってみます。 まずは、Workspace ONE UEMコンソールでの作業です。 すべての設定＞システム＞エンタープライズ統合＞Workspace ONE Access＞構成 へ移動し、「 エクスポート 」をクリックしてAirWatch認証局のルート証明書をエクスポートします。 次に、Windows向けにWorkspace ONE Access認証用証明書プロファイルを作成してデバイスに対して配信します。 SCEPペイロードを選択し、「 資格情報ソース 」は「 AirWatch認証局 」を選択します。証明書テンプレートは「 証明書（クラウド展開） 」です。 【補足】 上記のプロファイルで配信した証明書は 秘密キーのエクスポートができない ようになっているため、使い回しを防ぐことができます。つまり、私用のデバイスにインポートし直してログインしてしまおう...ということはできない仕組みになっているワケですね。 次はWorkspace ONE Accessの管理コンソールでの作業です。 IDとアクセス管理＞管理＞認証方法をクリックし、「 証明書（クラウドデプロイ） 」の設定を変更します。（UEMのプロファイルで選択した証明書テンプレートと同じ名前ですね。若干の誤差はありますが...） 始めに、「 証明書アダプタを有効にする 」にチェックを入れ、「 ルートおよび中間CA証明書 」のところには先ほどWorkspace ONE UEMからエクスポートした証明書をアップロードし、「 証明書の失効を有効にする 」にもチェックを入れておきます。 【補足】 公的認証局であっても、ここでルート証明書をアップロードしない限り証明書認証はできないので、今回の例では Workspace ONE UEM内部の認証局から発行されている証明書以外では認証できない 構成にすることができます。 少し下にスクロールして「 OCSPの失効を有効にする 」にチェックを入れ、「 OCSPレスポンダの署名証明書 」には...
コメントを投稿
続きを読む

Workspace ONE AccessからServiceNowにシングルサインオン(SAML)

以前、Workspace ONEと他システム間で、 OpenID Connect で連携する内容をポストしましたが、今回は SAML を利用したシングルサインオンの構成を検証してみました。 ServiceNow と SAML連携 して、WS1のポータルからシングルサインオンする構成を試してみます。 大枠の流れとしては以下の通りです。      1．ServiceNow(SP)のSAML認証設定          1.1． WS1 AccessからSAML連携に必要な情報を取得           1.2．SAML認証設定      2．WS1 Access(IDP)でSAML認証設定      3．動作確認 1.ServiceNow側(SP)でSAML認証設定 まずは、今回の構成ではSP(Service Provider)となるServiceNow側でSAMLによるシングルサインオンを可能とするように構成します。 1.1．WS1 Accessから S AML連携に必要な情報を取得 まずは、WS1 AccessのIDPメタデータのURLを取得します。 [カタログ]>[Webアプリケーション]をクリック後、[設定]をクリックします。 左ペインから[SAMLメタデータ]をクリック後、IDPメタデータの[URLをコピー]をクリックします。 クリップボードにコピーされるので、テキストエディタにでも貼り付けておきます。 次に、WS1 AccessのIDP署名証明書を取得します。 左ペインから、[SAMLメタデータ]をクリック後、署名証明書の[ダウンロード]をクリックします。 こんなファイルがダウンロードされます。 1.2．SAML認証設定 続いて、ServiceNow側のSAML認証設定を行います。 ServiceNowの管理コンソールにログインし、検索バーに[saml]と入力後、[SAML2 Single Sign-On]配下の[Certificate]をクリックします。 後で、使用するため先ほどダウンロードした、[signingCertificate.cer]をテキストエデ...
コメントを投稿
続きを読む

自分のデバイスは自分で管理

Workspace ONE UENにはセルフサービスポータル（SSP）という機能があります。 名前の通りセルフサービスで自身に紐付いているデバイスに対して色々できるポータルで、デバイスのステータスを確認したり、位置情報を確認してみたり、コマンドを実行したりと様々なことができます。 色々できるとなると、逆に誤操作などでデバイスワイプを実行してしまい意図せず初期化してしまったりするのではないか...という懸念が出てきますが、WS1 UEMのセルフサービスポータルではユーザーが実施可能な操作をカスタマイズできます。 例えば、あくまで情報参照用とするためにデバイス情報の表示の権限だけ与えておいたり、紛失したときの対策のために加入解除操作はできるようにしておく、など運用要件によりカスタマイズして利用できるというワケです。 ここでは、加入解除のみを実行できるようにカスタマイズしたSSPにログインし、ユーザー目線で実際に自分のデバイスを加入解除する、ということをやってみます。 実際にありそうなシーンと言えば、あまり考えたくありませんが、夜中に会社支給のデバイスの紛失に気付いてしまったときとかですかね... まずは、Workspace ONE UEMのSSPにログインします。 WebブラウザでWorkspace ONE UEMコンソールのURLの末尾にmydeviceを付けてEnterキーを押します。「https://cnXXX.awmdm.com/mydevice」みたいな感じです。 アクセス後は、ログイン方法などを選択後次ヘ進み、ユーザー名パスワードを入力してログインします。 今回は事前に権限を極限まで絞っているため「 企業情報ワイプ 」のみ表示されていますので、これをクリックします。 【補足】 画像に映っている通り、自分に紐付くデバイスが複数存在する場合もすべてSSPから管理できます。 すると、対象のデバイスで加入解除が実行され、企業データが削除されます。 ちなみに、上記の動作確認ではSSPの権限をかなり限定して企業情報ワイプしかできないようにしてますが、特に権限を限定しなければ「 企業情報ワイプ 」以外にも「 デバイスの位置情報を確認 」など様々なオプションが実行できますし、「 詳細に進む 」をクリックすると... デバイスの順守状態や適切にプロファイルが適用されているか、...
コメントを投稿
続きを読む