Quantcast
Channel: ネットワールド らぼ
Viewing all 459 articles
Browse latest View live

自動化, CI/CD と Nutanix Calm

$
0
0

本記事の原文はNutanix社のDirector, Services Strategy and Sachin Chheda, Global Accounts and Verticals MarketingであるVandana Rao氏, よるものです。

原文を参照したい方は「Automation, CI/CD and Nutanix Calm」をご覧ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ弊社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


65e087b7db5f4684a300716a7bc51f35_th

全ての産業においてデジタル化は機敏なソフトウェア開発をコアとして要求しており、組織が変化しソフトウェアをサービスとして提供し、効率を高めようが、より良いサービス、製品を提供しようが、ビジネス要件の変化に対応するためにソフトウェア開発の機敏性に対応してくことが重要なのです。

ソフトウェアがハードウェアを食す


Nutanixの他の人達は、いま求められている変化の為のサポートを得て適切な人を雇い、適切なプロセスとツールを導入する事が必要とされる組織の変化について広く話をしています。


広く定義されたCI/CD(CICD)は繰り返し開発、テスト、コードの展開を行うか、素人の面からだと開発とコードの提供はより信頼性があり、より頻繁であり手動で何かする必要が無いという事です。従来のウォーターフォール・モデルと比べてこの機敏なプロセスは無駄な労力を削減し、ビジネスが必要としている非常に高い反応性を可能にします。一定のビルド、テスト、ステージングと展開、しかしこれはまた潜在的に非常に大きな運用の負荷となります。

結果的にCI/CD方法論は素早く、高い自動化プロセスがビルドとテストの為に必要となります。

この自動化された方法はソースコード、レポジトリとビルド、ツールを含めたリソースを備えている必要があり、高いカスタム性と管理者、開発者の両社からの高い利用性が必要です。ほとんどすべてでコーディングにフォーカスしたスキルがあるDevチームとSLAに焦点を当てた運用チームが必要とされます。

Nutanixは単に必要なインフラストラクチャだけでなく、1クリックのシンプルさとCI/CD自動化に対するコンサルティングサービスを提供しています。

Nutanix Calmと一緒に一歩を踏み出してみましょう。Calmはアプリケーションライフサイクル管理とマルチクラウドに対するオーケストレーションを提供しており、高度なIT運用管理者からアクティブコーディング開発者がロールアウトをこれまでよりも早く行うことが出来る一方で自動化テストと品質管理の機能を強化する事で全てのレンジの方の効率を向上するか、また単に組織のCI/CDパイプラインの作成を手助けする事になります。

アプリケーションの自動展開だけでなく、CI/CDスタックの解決の為の展開という事を考慮していくつかのシナリオとCalmのデモについて話してみましょう。

以下のVide(外部リンク)を飛ばしたい方はSenariosを見てみましょう


YouTube: CI/CD Pipeline with Nutanix Calm

シナリオ #1:


担当者: インフラ管理者

目的:完全なCI/CDソリューションを展開するので、チームは一貫性の取れたツールセットの展開を行います。


ツール:Docker , Gitolite , Jenkins , JFrog や開発用のワークステーション(開発コードを利用した開発者の為のLinux仮想マシン)

5674858a116746a68dfdd3162973bf3f

実現するCalmブループリントのタスク:

  1. サンプルのCI/CD環境へのインスタント化に必要なすべてのアプリケーションを展開します。この組み込みはPrivate Docker Registry , Git repository , Artifactory , Jenkinsを含みます。
  2. 全てのコンポーネントをシームレスにSSHキーや認証を利用して組み込みます
  3. Jenkinsからすべてのコンポーネントにアクセスできるように構成します
  4. Jenkinsをビルド、サンプルアプリケーションの展開が行えるように事前構成します
  5. 開発者ワークステーションへ事前構成のアプリケーションと展開します

シナリオ #2:


担当:DevチームのIT管理者


目的:開発者の生産性を高める為、必要に応じてすぐに開発用ワークステーションを展開する

ツール:構成された開発ツールと開発者用のワークステーション


実現するCalmブループリントのタスク:

  1. CI/CDツールの事前設定を展開を開発者ワークステーション内で実施、これにより開発者は構成などに時間を割くことなくアプリケーション開発に専念できます

シナリオ #3:


担当: 開発者

目的:テストとアプリケーションライスサイクル全体のサービスのコードの展開

ソフトウェア開発: 3 Tier アプリケーションスタック、Webサーバ、Appサーバ、DBサーバ


実現するCalmブループリントのタスク:

ノート:開発者はシナリオ1で作成したツールチェーンをNutanix Calmを呼び出すためにJenkins(REST APIs)を利用する事が出来ます。

  • Jenkinsの活用で全体のビルドの自動化の呼びだし、テストと公開フェーズを実施
  • Nginx Web Server , node.js , MongoDB を含めた3Tierアプリケーションの自動展開

CalmはNutanix ソリューションファミリの一部として再リリースして以来、Calmが私たちがアプリケーションライフサイクル管理をシンプルにするベースのインストールを手助けしており、全てのNutanixをご利用のお客様は25VMのライセンスを持っていますので、是非これを期にお試し頂ければと思います。



👉 Continue the conversation in our Nutanix Calm forums.

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

記事担当者 : SI技術本部 カッシー @Networld_NTNX


Citrix MCS on Nutanix AHV : クローンのパワーを解放せよ

$
0
0

本記事の原文はNutanix社のEUC Solution ArchitectであるKees Baggerman氏によるものです。
原文を参照したい方は「Citrix MCS on Nutanix AHV: Unleashing the power of clones!」をご覧ください。
情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
弊社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら
ネットワールドのNutanix関連情報は、ぜひ弊社のポータルから取得ください。
(初回はID、パスワードの取得が必要です)


 Citrix MCSプラグインのリリースでNutanix AHVのクローンに関する内部動作について多くの質問が寄せられました。ここでは、AHVがCitrix MCS展開でクローンをどのように使っているかを理解するために役立つ内容をご紹介致します。

 以前の記事で解説したように、Nutanixはシャドウクローンを実装することでvSphereやHyper-V環境でのデータローカリティに関する問題を解決してきました。

Q「シャドウクローンはAHVでのCitrix MCSにも役立ちますか?」
 これに対する端的な回答は「いいえ」です。
 もうちょっと詳しく解説しますと、シャドウクローンは基本的に リンククローンの仕組み や AHVでは利用できないView Composerのようなマルチリードが発生する環境 でデータローカリティを実現させる目的で作られているということです。

 このシャドウクローンがどのように機能するかということですが、Citrix SynergyでMartijn Bosschaartと共同で発表したスライドの1枚です。

3Tier環境でのMCS
Syn219_mcs_sharedstoragepngnggid033

vSphereまたはHyper-Vを使用したNutanix環境でのMCS
Syn219_shadowclonespngnggid03377ngg

 このスライドの要点は以下の通りです。

  • すべてのReadおよびWriteはローカルで完結し、ユーザーのパフォーマンスが向上します。
  • Readはネットワークトラフィックを発生させず、他のワークロードの帯域幅が広がります。
  • 集中管理されたストレージ上のReadのホットスポットを回避します。

では、「AHVでシャドウクローンが有効とならないのはなぜでしょう?」
 まず、それはAHVのクローンの仕組みに起因します。AHVのクローンは 仮想マシンのメタデータのクローン や スナップショットの取得 と同じように超高速で生成されます。
 次に、それはAHVがマスターディスクへのソフトポインタを採用しているためです。キャッシュのローカリティあるいはエクステントのローカリティ と メタデータ を実装しているため、このマスターディスクはノードのローカルとしてアクセスすることができます。

 それではAHVのディスクレイアウトを簡単に見てみましょう。

AHV上のMCSベースのVMディスクレイアウトSyn219_ahvfilelayoutpngnggid03376ng

 このスライドに関する注意事項

  • Nutanix AHVにはIDディスクと差分ディスクの2つのディスクしかありません。
  • 割り当てられたストレージの一部が事前設定されています。

 ここでのポイントはCopy on Readであるということです。このメカニズムはマスターイメージに最初のReadがヒットした後、VMにローカルなReadキャッシュを生成しますが、これはより多くのストレージを消費する可能性があります。Michael Websterのブログにはこの効率性に関する実環境での例が掲載されています。

 このソリューションではAHV上のCitrix MCSでクローンが展開されると、すぐに利用可能なデータローカリティが提供されます。
 AHVに備わったAOSとPrismが提供するストレージネイティブのパワーを組み合わせると、シンプルで高密度なプラットフォームを提供するCitrix XenDesktop/XenAppソリューションを構築できます。このモジュール方式のポッドベースのアプローチにより、導入時間を極限まで小さくし、簡単かつ効率的に環境を拡張できるようになります。

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

VPNゲートウェイを使ってFrameをローカルネットワークへ接続する方法

$
0
0

本記事の原文はFrame社(Nutanix社)のテクニカルライターであるAmanda Rhyne氏によるものです。

原文を参照したい方は「Connect Frame to your local network with a VPN Gateway」をご覧ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ弊社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


 私たちのミッションのひとつはお客様がFrameを使って独自のワークフローや業務環境のセットアップが行えるようにお手伝いをすることです。

 その方法として、以前のブログで掲載したようにローカルファイルへのアクセス、ユーティリティサーバーのネットワークファイル共有としての利用、パブリッククラウドストレージをFrame上でシームレスに利用することが挙げられます。

 

 もしクラウド上にあるFrameから社内リソース(オンプレミス)にアクセスする必要がある場合は、この2つの間でVPN接続を構成することもできます。FrameではAWSのVirtual Private Cloud (VPC) または AzureのVirtual Network (VNET) 経由で社内のローカルネットワークに接続することができます。

すべてがクラウドで構成された環境の場合

 デフォルトではFrameアカウントは制限されており、世界中からの外部アクセスがブロックされています。一方、一般的なパブリッククラウド上に配置されたリソースは送信元を制限しないので、Frameから簡単にアクセスできます。多くのお客様はユーティリティサーバーを活用し、リソースをFrameに移行させ、クラウドのセキュリティ・移植性・スケーラビリティ・スピードを利用してクラウドから業務運用しています。

VPC内のすべてのリソースを持つAWSのFrameの図
(Azureでも同様にVNETと呼ばれます)

0_hoksqtdxxq2ivibw_

ハイブリッド環境の場合

 しかしながら、我々はお客様のニーズのすべてが先述のようにそれほど単純ではないことも知っており、そのための選択肢も提供しています。外部リソースにアクセスする必要がある場合は、VPNトンネルが最善の方法かもしれません。

 以下に示すネットワークトポロジーは、多くのお客様が支社から本社へVPN接続する方法と非常によく似ています。ご自身のFrameを会社に接続すると、ユーザーはライセンスサーバー、ネットワークファイル共有、データベースなどの社内リソースへFrameからアクセスできるようになります。

1_kiwnzae_km0hepqdz4n0lq

 Frameは、Cisco、Juniper、Dell / SonicWall、Palo Alto Networksなどのハードウェアおよびソフトウェア両方のVPNオプションをサポートしています。サポートされているデバイスの一覧については、ここをクリックしてください。選択したVPNクライアントを使用して(スプリットトンネル構成を介して) Frameを既存のVPNアプライアンスに接続できます。

 FrameにはカスタムVPNに関するリクエストフォームがありますので、お客様のご要望に対応することが可能です。リクエストを完了するには具体的な情報が必要になるため、ネットワーク管理者にこの部分の支援を依頼することをお勧めします。また、お客様はオンプレミスに配置されたネットワーク機器でVPNのエンドポイントを構成する方法を把握しておく必要があります。

2_cfhkwqe77xurbqfrn4lama

上記ページへのダイレクトリンクはこちら

考慮事項

 ハードウェアベースのIPSec VPN接続を使用すると、以下のようなメリットがあります。

  • クラウド内の管理対象エンドポイントには、複数データセンターの冗長性と自動フェイルオーバーが含まれます。
  • 既存のVPN機器とそれに関する運用手順を流用できます。
  • 既存のインターネット接続を流用できます。

 その他、考慮すべき制限事項は以下の通りです。

  • ネットワークの待機時間・変動性、および可用性はご利用のネットワーク状況によって異なります。
  • 環境内のエンドポイントに冗長性とフェイルオーバーの実装要否をご検討いただく必要があります。
  • 動的ルーティングにBGP (Border Gateway Protocol) を利用する場合、デバイスはシングルホップのBGPをサポートしている必要があります。

追加の詳細情報

 お客様には千差万別のユースケースがあるかと思います。私たちはお客様に応じた最適なツールとリソースをご利用いただき、セキュアにご要望を実現するためのお手伝いを致します。AWSまたはAzureでVPNゲートウェイを使用する方法の詳細については、以下のページをご覧ください。

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

Nutanix レジリエンシー – パート 10 – Disk スクラブ / チェックサム

$
0
0

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、

そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。

原文を参照したい方はNutanix Scalability – Part 5 – Scaling Storage Performance for Physical Machinesをご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


このシリーズでは私はどれだけレジリエントがNutanix Platformでは素晴らしいか

障害中のあたしい書込みデータ、障害が発生した後にその後のリスクを最小限にするためのリビルドの機能を含めてカバーしていきています。

全てのこの情報にも関わらず、他のベンダーは依然としてNutanixが提供している 

リビルドパフォーマンスは問題ではなく、二つのコピーセットが消えたらという?というデータの信頼性という簡単に言え、両方のデータが消える可能性は極めて低いことについて触れていますが、もちろんNutanixはこのようなお客様に対してデータの3重化をサポートしています。

それではパート10に行きましょう。

ここではDiskスクラブとチェックサムという2つお客様はRF2,3の展開が非常にレジリエンシーがありデータロストする可能性がほとんどないという事を学んでいただけるはずです。

ではチェックサムから始めましょう、チェックサムとはなんでしょうか?

チェックサムは書込み操作の間に作成された小さいデータを後に読み込みデータが正しいかを確認します。

一方 Disk スクラブは定期的にデータの一貫性を確認するバックグラウンド処理となり、いかなるエラーでも発生すれば、Diskスクラブはシングルコレクタブルエラーを実施するようになります。

Nutanixは全ての書込み操作(RF2 又は3)へのチェックサムを行い、全てのリード操作でチェックサムを確かめます!この意味はデータの完全性がIOパスの一部で、スキップまたはOFFにされていない事になります。

データの完全性は全てのストレージPlatformの一番の優先事項であり、Nutanixが決して無効にしないオプションなのです。

Nutanixはリードのチェックサムを行っている以上、データがアクセスされると常にチェックされる事となり、もしエラーが発生すした場合はNutanix AOSは自動的にRFコピーからデータを復元しIOのサービス、同時にデータロスが発生しないように修復します。

Nutanixがノード/ドライブまたはExtent(1MB のブロックデータ)から復旧するスピードはデータの完全性には非常に重要な事です。

コールドデータについてはどうか??

多くの環境では非常に多くのコールドデータを持っており、つまりアクセスが頻繁にされないという事になるため、データのチェックサムが行われず、頻繁にアクセスされないデータのチェックは全くされないことになってしまいます。データがアクセスされない場合、どのようにしてデータを保護するのでしょうか?

単純です、Diskスクラブになります。

フロントエンドの読み込み操作を通しているデータ(VM/Appからの読み込みデータ)に関しては

一日に一回のNutanixのディスクスクラブ実行がコールドデータをチェックします。

Diskスクラブタスクはクラスタ内の全てのDiskへ実施するため、ドライブ障害や、Extent(1M ブロックデータ),データがある2つのディスクの同時障害というような複数の同時障害が発生する可能性は極めて低いのです。これはRF2を利用した場合を仮定しています。

データの障害は完全に直近24時間でデータの読み込みが発生していなかった事、バックグラウンドディスクスクラブが2つのコピーデータに対して実施されていなかったこと、AOSの予測ドライブ障害がドライブ障害を発見できなかった、AOSのPredictiveなドライブ障害がドライブ障害を検知できない、またそこへすでにデータの再保護がされてしまっている事が同時に発生している必要があります。

いま、シナリオが発生したと仮定します、ドライブ障害は破損したデータブロックと同じストアがある必要があり、NX3460などの4ノードの小さいクラスタでさえあっても、ドライブは24となるため可能性は非常にすくなくなります。クラスタが大きくなればなるほど、この可能性は低くなりますし、以前のシリーズでお話したとおり、リビルドの時間は早くなります。

まだとてもリスクがあると感じ、全てのイベントを完全に列挙してからRF3を展開し3ノード障害に加えてデータロスを起こすために奇跡を起こす必要があります。

VSANを展開しているとDisk スクラブは年に一度実行され、VMwareは頻繁にチェックサムをOFFにする事を推奨しています。SAP HANAドキュメントもそうでしたが後にデータロスのリスクがあるため、このドキュメントは更新されています。

NutanixはまたDiskスクラブアクティビティを監視する機能があります。

下にあるスクリーンショットは2TB SATAディスクで75%程利用されているDisk ID 126のディスクスキャンを表しています。

Diskscrubbingstats

Disk126

AOSはディスクスクラブを保証し、ディスクのサイズに関わらず24時間ごとに実施します。上のスクリーンショットはスキャンが 48158724ms走っているものとなります。 googleによると13.3時間で556459ms(0.15hrs)でETAが完了します。

Scanduration

データが動的に容量、パフォーマンスを基準に分散するADSFの性質と組み合わせると、Nutanix Clusterは各ノードの複数の同時ディスク障害に対応する機能を持っており、チェックサムは全てのリードライト操作で実施され、ディスクスクラブは毎日完了します。プロアクティブなドライブ健康状態の監視はドライブ障害が発生する様々なケースのデータ再保護が行われます。

同じく、ADSFはデータのリビルドを行いRF2を利用していたとしても簡単に素晴らしいレジリエンシーを提供するのです。

まだ満足していない様でしたらRF3へ変更し、よりレジリエンシーを高めるようにしてみましょう。

レジリエンシーファクター,vSANでいうFailure Tolerateを考慮するとき、それぞれ2重化でも動作がことなりますので、間違えないようにしまし、それぞれあったものを検討頂ければと思います。

以下はその他の Josh Odger氏が投稿しているBlogの外部リンクとなります

Index:
Part 1 – Node failure rebuild performance
Part 2 – Converting from RF2 to RF3
Part 3 – Node failure rebuild performance with RF3
Part 4 – Converting RF3 to Erasure Coding (EC-X)
Part 5 – Read I/O during CVM maintenance or failures
Part 6 – Write I/O during CVM maintenance or failures
Part 7 – Read & Write I/O during Hypervisor upgrades
Part 8 – Node failure rebuild performance with RF3 & Erasure Coding (EC-X)
Part 9 – Self healing
Part 10: Nutanix Resiliency – Part 10 – Disk Scrubbing / Checksums

記事担当者 : SI技術本部 カッシー @Networld_NTNX

コピーデータ活用~連載シリーズ CDM製品パイオニアActifio(アクティフィオ)のご紹介! ~ 設定編1~

$
0
0

こんにちは。前回、Actifio (アクティフィオ) 製品のコンセプトをご紹介いたしましたが、Actifio の管理インターフェース、リモートサイトへの DR 構成、VMware vSphere 環境の仮想マシンのバックアップ設定方法をご紹介いたします。

 

【Actifio 管理インターフェース】

Actifio のインターフェースには、インストール型の管理コンソール "Actifio Desktop"というクライアントアプリケーション(GUI) が提供されています。管理コンソール画面を通じて、対象データの取り込みやコピーデータのマウントなどの各種の設定が直感的に操作てきます。

 

001_3

 

また、Actifio には、Role Based Access Control(RBAC) 機能が実装されていますので、グループまたはユーザ毎に、対象サーバの保護ジョブの実行やコピーデータ利用の操作などを制限して運用することもできます。

 

【Actidio データ保護ポリシー: SLA (Serivce Level Agreement)】

Actifio では、データ保護レベルを統一した SLA (Service Level Agreement) というテンプレートを使用して、バックアップの設定・管理を行います。

 

002

  

【Actifio レプリケーションとクラウドストレージへのデータ転送】

Actifio のレプリケーション機能は、プールの構成と同様に要件に応じて、複数の転送方式を使用することができます。StreamSnap は Snapshot プールからリモートの Actifio アプライアンスの Snapshot プールへ転送する動作、1時間に1回など比較的短い転送間隔に対応できる方式です。

 

もう1つの方式の Dedup Replication は、Dedup プール内の重複排除済のデータを転送する方式ですが、ブロック送信前にリモート側に対して同一ブロックの存在を確認する重複排除転送プロトコルを実装しているため、ネットワーク回線帯域の使用を抑えたレプリケーションを実施することができます。

 

DAR(Dedup Async Replication)は、Dedup Replication の転送効率とリモート側でのコピーデータの即時利用ニーズを両立した方式で、リモート側のDedupプールへの
転送が完了すると自動的にSnapshotプールへ復元・展開処理が行われます。 

003

 

【Dedup Async Replication の流れ】

① VMware API 経由で差分ブロッックを取得しSnapshot Pool に格納

②③ SnapShot 内部の差分ブロックを重複除外しながら転送

④ 重複除外データから差分ブロックを再現し、Snapshot Pool のVMイメージを更新

 

迅速なVMの復旧として、Actifio ReadyVM が提供されています。この機能は、ローカルサイトまたはリモートサイトで障害が発生したしたVMを瞬時にマウント、またはリカバリすることができます。ReadyVM を使用して、ディザスタリカバリテストをオンデマンドで行うこともできます。

 

004 

【ReadyVM の流れ】

① VMware API 経由で増分ブロッックを取得しSnapshot Pool に格納

②③ SnapShot 内部の増分ブロックを重複除外しながら転送

④ 重複除外データから増分ブロックを再現し、災対用ストレージのVMイメージを更新

 

今回、VMware vSphere 環境の仮想マシンのバックアップ設定手順をご説明します。バックアップの設定から開始までは、以下のステップで行います。

 

  • VMware vCenter の登録

    Actifio Desktop の Domain Manager から vCenter の登録を行います。

    006

     
  • ESXi ホストの iSCSI の登録
    Actifio Desktop の Domain Manager からバックアップデータ転送用の iSCSI を設定します。

    007

     

  • バックアップ対象仮想マシンの登録
    Actifio Desktop の Application Manager からバックアップ対象仮想マシンを検索して登録します。

    008 

  • バックアップテンプレート SLA の設定/割り当て

    Actifio Desktop の SLA Architect からバックアップのスケジュール保持期間や保持期間を設定し、バックアップ対象仮想マシンにSLAを割り当てます。

    010

    011

     
  • バックアップ開始

    SLA の設定に従い、バックアップが実施されます。

    012

 

バックアップジョブの設定も従来のバックアップと違い、ポリシーベースで管理し、設定手順もシンプルな手順で対応することができます。次回、リモートサイトへのレプリケーションをご紹介いたします。

 

今月 18日に弊社開催の「次世代バックアップソリューション Day 2018 ~ガチンコ対決~」というイベントに多くのお客様にご参加いただきました。 Actifio、Cohesity、Rubrik 3社で各社のバックアップアプライアンスの魅力をアピールいただき、お客様からの注目も高く、イベントも大盛況で終わりました。

 

Actifio、Cohesity、Rubrik 3社の取扱いは弊社のみですので、ご興味のある製品がありましたら、ぜひ担当営業までご相談ください。最後までお読みいただきありがとうございました!

 

【過去の掲載】 

 

Edit by :バックアップ製品担当 松村

Nutanix Filesのデータ保護

$
0
0

本記事の原文はもともとNutanix社のVP,Engineering のVishal Sinha 氏によるものです。

原文を参照したい方はComprehensive Data Protection with Nutanix Filesご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


障害はデータセンタ内のいかなるレベルでも発生する事があります。ディスクも障害となりますし、ノードも物理的に損傷を受けるかもしれません、またはデーターセンタが災害によりダウンする事も考えられます。またデータは誤った操作により失うかもしれません。

それは削除であったり、意図しない上書き、またはマルウェアにりそうさせるかもしれません。

Nutanix filesはデータ保護ソリューションでデータを安全に保護します。


ディスク障害とノード障害に対するデータ保護

Nutanix FilesはAOSへ影響しながら次の障害に対する保護を提供します。

ディスク障害 - ディスクに障害が発生した際、データは自動的にアクセス可能な他のノードへパフォーマンスの影響なしにアクセスできます。Nutanixプラットフォームはデータ保護の為のハードウェアRAIDには依存しません。

一度壊れたディスクが交換されると新しいディスクへリビルド処理がクラスタ内の全てのノードを同時に利用して実施します。


ノード障害 - データの冗長性はノード障害が発生したとしても変わりません。データはは他のノードのレプリカがまだ利用できますし、ノードが交換された際はデータは新しいノードにリビルドされます。


Block 障害– Nutanix Filesを含むクラスタは"Block Aware"です。つまりこれはデータのコピーを同じブロックに配置をしないことになります。

ブロックはラックマウントで1~4ノードでなりたっており、複数ノードのブロックでは電源、FANがブロックで共有される唯一の構成要素となります。

Block Awareness機能なしだとNutanix Clusterは一つのノード障害に対応できますが、Block Awarenessと構成すれば、ブロック内の複数のノードがダウンしてもクラスタは稼働します。

仮想マシンも同様に稼働しますが、これはクラスタの構成データや、仮想マシンのレプリカ、メタデータを他のブロックに保存するからです。

この機能は特定の条件下になると自動的に有効かされます

(ただし Proライセンスが別途必要となりますので、ご注意ください)



ローカル、リモートスナップショットを利用したファイルサーバレベルの障害に対するデータ保護

Nutanix Filesはサイト障害からのNutanix Filesインスタンスの保護を実施するファイルサーバレベルでのデータ保護を提供します。

ファイルサーバが作成されると、Nutanix Filesは自動的にProtection Domainも作成しこのProtection Domain にはファイルサーバ(VM , Volume Group)が含まれます


管理者がする事はいつデータのスナップショットをとるかをスケジュールします。

リテンションポリシーでどの位の期間スナップショットを保持するか、スナップショットをローカルに置くのか、リモートサイトに置くのか、リモートサイトの場合は1対多、多対1、多対多の複製をサポートしているので、管理者は全てのワークロードを前サイトにまたがって保護する事が出来るのです。

サードパーティバックアップの為のChanged File Tracking (CFT)

殆どの存在するソリューションは20年以上のNDNPの技術に頼っており、これはNutanix Filesなどのスケールアウトファイルサーバや、複数ヘッドのサーバといった、スケールモデルをサポートしていません。

Nutanix FilesはCFT技術を提供する事でスケールアウトファイルサーバ(Nutanix Files)のバックアップを行えるようになるのです。

これを利用するメリットをいくつか説明します。



Point-in-time backup:この機能は全てのファイルとディレクトリの point-in-timeバックアップを提供するので、もしバックアップに非常に時間がかかっていても実際にファイルのバックアップがいつ行われているのか推測する必要がなくなります。

“In use” files backup:多くの従来のバックアップソリューションでは使用中のファイルはバックアップされません。CFTでは全てのファイルまたはディレクトリを状態を関係なくバックアップします。

Smart Incremental backup:CFTは前回のスナップショットとユーザが差分バックアップを行うための全てのファイル、ディレクトリのトラックを保持します。NDMPではバックアップごとにすべての変更点をスキャンします。CFTはバックアップの時間を削減する事になります。


Fast backup:CFTは複数の同時ストリームをシングルファイルサーバVMに適用するだけでなく、複数のパラレルバックアップストリームをすべてのファイルサーバVMで活用できるようにします。例えば16VMからなるNutanix Files Clusterがあるとすると、一つのファイルサーバVM毎に2つのバックアップストリームを同時に実行すると仮定し同じファイルサーバからは32のパラレルバックアップを一度に実施できるのです。

CFTを使ったファイルサーバのバックアップでは最初にフルバックアップを取得、その後は差分のバックアップとなります。

ヒューマンエラー、予期せぬアクシデント、悪意のある攻撃からのデータ保護

誤ったデータ削除、ランサムウェアや悪意のある攻撃によるデータ消失に対してNutanix FilesはSelf-Service-Restore(SSR)機能を提供する事でユーザはWindows Previos Version(WPV)を利用して以前のバージョンからデータをコピー、復元することが出来ます。

管理者はSSRをファイルサーバレベルか共有レベルで構成できますし、SSRスナップショットは読み込み専用でPoint-in-timeコピーとなります。

下の画像はWindows OSでどのように以前のファイルを復元するかを示しています。



以下の図ではNutanix Filesがサポートしているデータ保護の仕組みになります。

Filesをファイルサーバとして利用する場合にもNutanix本来の冗長性に加えてFiles側でのデータ保護の仕組みを活用する事が出来るわけです。


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

記事担当者 : SI技術本部 カッシー @Networld_NTNX

IBM Cloud Private 3.1.1 Vulnerability Advisorを追加してイメージの脆弱性をスキャンしてみよう

$
0
0

こんにちは。IBM Cloud Privateについて、かなり間が空きましたが、前々回にインストールの内容を投稿しました。

今回は脆弱性アドバイザー(Vulnerability Advisor)を追加してみたいと思います。

脆弱性アドバイザーって何?

ドキュメント上では下記のように説明されています。

脆弱性アドバイザーは、IBM® やサード・パーティーによって提供されるか、組織のレジストリー名前空間に追加された、コンテナー・イメージのセキュリティー状況を検査します。 Container Scanner が各クラスターにインストールされている場合、脆弱性アドバイザーは、実行中のコンテナーの状況も検査します。 https://console.bluemix.net/docs/services/va/va_index.html#about

ICPで管理しているイメージや稼働しているコンテナー上で脆弱性をもつパッケージがないかと設定について問題がないかをレポートしてくれます。
また、この機能の開発は日本のラボで開発されているとのことです。

既存のICPの環境にVulnerability Advisor(VA)を追加して、イメージのスキャンとコンテナーのスキャンまでできることを確認してみたいと思います。

※注意※既存環境が存在しており、その環境にWorkerノードを追加構築していく想定の手順となっていますので、環境がまだないという方はインストール方法を参考に作ってみていただければと思います。 また、商用版のIBM Cloud Privateを想定した手順となっておりますので、CE版での実施は想定しておりません。(VAはCE版では利用できません。) あらかじめご了承ください。

また、今回の環境はICP 3.1.1の環境をベースに作成しています。
前回投稿したICPのインストール手順では3.1.0を利用していますが、今回手順については3.1.0でも変わりませんので、各コマンド部分の3.1.1部分を3.1.0に読み替えて実施してみてください。

 

脆弱性アドバイザー(VA)のインストール

既存環境

サーバースペックは同じもので2台のサーバーがあります。

OSRedHat Endterprise Linux 7.4
物理/仮想仮想
CPU(Core)8
Memory24GB
Disk300GB
NIC1つ

Master ServerとWorker Serverが1台ずつあります。 ICPのバージョンは3.1.1になります。

以前、投稿した手順は3.1.0になります。3.1.1でも同様の手順でインストールできます。
また、この手順は3.1.0でも同様の作業内容になりますので、記載されているバイナリ名や、設定名等、 3.1.1となっている部分は 3.1.0 と読み替えて手順を実施してください。

 

事前準備

WorkerやVAにするノードを準備します。
今回は以既存環境と同じスペックのRHELの仮想マシンと同じものを用意します。

Linux on PowerやLinux on IBM Z でも動作は可能(VAは制限あり)ですので、動作環境の詳細は下記をご参照ください。
https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/supported_system_config/supported_os.html

 

追加するノード

追加するノードは下記になります。

Host nameIP作業ユーザー
icp-poc-va1.icp.localxxx.xxx.xxx.158root

 

追加ノードで行う作業

追加するノードでは下記の事を行います。

  1. 通信ポートの確認
  2. SE Linux の無効化、Firewallの無効化
  3. /etc/hostsを設定
  4. 時刻の同期
  5. Python のインストール(の確認)
  6. Dockerのインストール
  7. (後から作業) sshサービスの再起動
 

通信ポートの確認

下記コマンドを実行してなにも表示されないことを確認します。

ss -tnlp | awk '{print $4}' | egrep -w "8001|8500|3306"

 

SE Linux の無効化、Firewallの無効化

SE LinuxとFirewallを無効化します。
SE Linuxは /etc/selinux/configをdisableに変更します。
Firewallは下記のコマンドを実行します。

systemctl stop firewalld
systemctl disable firewalld
 

/etc/hostsを設定

クラスターに存在するすべてのノード(Master/Worker/VA/Management/Proxy)を /etc/hosts に指定します。

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local
xxx.xxx.xxx.158 icp-poc-va1.icp.local
 

時刻の同期

追加するノードと既存のサーバー群と時刻の差が出ないように時刻同期を行います。
時刻同期方法は各Linuxのドキュメントをご確認ください。

RHELで時刻、時刻同期の設定の確認は下記コマンドでできます。

# timedatectl
Local time: Tue 2019-01-08 11:01:18 JST
Universal time: Tue 2019-01-08 02:01:18 UTC
RTC time: Tue 2019-01-08 02:01:17
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
 

Python のインストール(の確認)

Pythonがインストールされていることを確認します。
サポートされているPythonのバージョンは、2.6,2.7,3.5以上になります。

# python --version
Python 2.7.5
 

Dockerのインストール

Dockerをインストールします。DockerのバイナリーはIBM社から提供されています。

  • IBM Cloud Private 3.1.1 Docker for Linux (x86_64) (CNXD2EN )
    size: 141MB

このファイルをノード上にコピーし実行します。

cd /(ファイルをコピーした場所)
./icp-docker-18.03.1_x86_64.bin --install

※このとき、内部で別のコンポーネントをyumでインストールします。

dockerが自動起動されるように設定します。

systemctl start docker
systemctl enable docker
 

(後から作業) sshサービスの再起動

既存のMaster ServerからSSH Keyをコピーした後にSSH Serviceの再起動を行います。
後述の手順内で再度ご案内します。


Master Serverで行う作業

実際のインストール作業については既存のMaster Serverから行います。

  • SSH Keyのコピー
  • (後から作業) sshサービスの再起動
  • バイナリーファイルの確認
  • ノードへのVAインストールの実施
  • ノードの状態の確認
  • Master Serverへの機能のAddon

SSH Keyのコピー

Master Server上からノードにSSH Keyをコピーします。

ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<node_ip_address>

今回は、下記の情報を使ってコマンドを実行します。

usernode_ip_address
rootxxx.xxx.xxx.158
ssh-copy-id -i ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.158
 

!!!ノードで作業!!! sshサービスの再起動

ノード上でSSH Serviceを再起動します。

systemctl restart sshd

 

バイナリーファイルの確認

下記にLinux用のバイナリーファイルがあることを確認します。
インストールパスを変更している場合は適宜読み替えてください。

PathFile name
/opt/ibm-cloud-private-3.1.1/cluster/imagesibm-cloud-private-x86_64-3.1.1.tar.gz

コマンド

# ls /opt/ibm-cloud-private-3.1.1/cluster/images ibm-cloud-private-x86_64-3.1.1.tar.gz
 
VAの追加

VAの追加は下記のコマンドを参考に実行します。

docker run --rm -t -e LICENSE=accept --net=host -v \
$(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee va -l \
ip_address_vanode1,ip_address_vanode2

IPアドレス xxx.xxx.xxx.158をVAとして追加しますので、実行するコマンドは下記になります。

cd /opt/ibm-cloud-private-3.1.1/cluster
docker run --rm -t -e LICENSE=accept --net=host -v \
$(pwd):/installer/cluster ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee va -l \
xxx.xxx.xxx.158
 

ノードの状態の確認

追加したノードがVAとして登録されているか確認します。
ICP管理コンソールから[プラットホーム]-[ノード]を開きます。
IPアドレスの末尾 158の役割に VAと記載されていることを確認します。

20190109_15h16_01a_2

Master Serverへの機能のAddon

最後にMaster ServerとVAノードに機能をデプロイ(アドオン)します。

Master Server上のConfig.yamlを編集します。

vi /opt/ibm-cloud-private-3.1.1/cluster/config.yaml

変更前

## You can disable following services if they are not needed:
# custom-metrics-adapter
# image-security-enforcement
# istio
# metering
# monitoring
# service-catalog
# storage-minio
# storage-glusterfs
# vulnerability-advisor
management_services:
istio: disabled
vulnerability-advisor: disabled
storage-glusterfs: disabled
storage-minio: disabled

変更後

## You can disable following services if they are not needed:
# custom-metrics-adapter
# image-security-enforcement
# istio
# metering
# monitoring
# service-catalog
# storage-minio
# storage-glusterfs
# vulnerability-advisor
management_services:
istio: disabled
vulnerability-advisor: enabled     #←disabledからenabledに変更
storage-glusterfs: disabled
storage-minio: disabled
 

下記の内容を参考にコマンドを実行します。

docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-ARCH:3.1.1-ee addon

Dockerイメージ名が異なりますので、下記のように変更して実行します。

cd /opt/ibm-cloud-private-3.1.1/cluster
docker run --rm -t -e LICENSE=accept --net=host -v $(pwd):/installer/cluster ibmcom/icp-inception-amd64:3.1.1-ee addon

 

VA動作の確認

VAの機能追加完了後は、管理コンソール上でスキャンの状況やレポートが確認できるようになります。

 

管理コンソールのログアウト/ログイン

管理コンソールにログインした状態で機能の追加を行った場合は画面が正常に表示されない場合がありますので、管理コンソールからログアウトし、再度ログインします。

20190110_11h26_17_2

コンテナーイメージのスキャン状況の確認

VAの機能が有効化されると自動的にコンテナーイメージのスキャンが実行されます。
すべてのイメージをスキャンするには時間がかかりますが、スキャン済みのものからステータスの確認ができますので開いています。

  1. 管理コンソールを開きます。

  2. メニューから[コンテナー・イメージ]を選択します。

    20190110_11h28_01_2

  3. 一覧が表示されます。セキュリティー・スキャンのステータスに 成功 or 失敗しましたのステータスがあるものはスキャンが完了しています。 

    20190109_15h33_34_2

  4. 失敗している ibmcom/curl-amd64をクリックします。

    20190109_15h36_19a

  5. スキャンの結果、問題がいくつあるか表示されています。
    スキャンの表示をクリックします。

    20190109_15h36_24a_2

  6. スキャン結果のレポートが表示されます。
    Organizational Policiesでは違反理由が表示されています。
    今回はイメージ内にインストールされたパッケージ上に既知の脆弱性が含まれていることが示されています。

    20190109_15h36_32_2

  7. [vulnerable Packages]のタブをクリックします。
    ここでは脆弱性の影響を受けるパッケージの情報が表示されます。

    20190109_15h36_38_2

  8. [Container Settings]のタブをクリックします。
    ここではコンテナーの設定に対して潜在的な脆弱性の問題や推奨されてる設定について表示されます。

    20190109_15h36_48_2


    今回は見つかっていませんが、Security MisconfigurationsやRisk Analysisの情報も確認できます。

  9. 次に稼働しているContainerのスキャンレポートを確認します。
    管理コンソールから[ツール]-[脆弱性アドバイザー]を選択します。
    ※ツールメニューが表示されない場合は管理コンソールのログアウト/ログインを行ってください。

    20190110_11h37_50_2

  10. [kube-system]を選択します。

    20190110_11h40_05a_2

  11. 別のタブが開き、[Vulnerability Advisor(List Containers)]が表示されます。
    Filterに[mariadb]と入力し、Organizational Policiesのステータスが Violationとなっているリストをクリックします。

    20190110_09h36_09a_2

  12. Imageスキャンの結果と同じように Organizational Policies / Vulnerable Packages / Container Settings / Security Misconfigurations / Risk Analysis の情報が表示されます。

    20190110_09h39_05

以上がVAの展開からスキャンの結果の表示までの手順になります。
このほかにも **Mutation Advisor というContainer上で変更があった場合に検知する機能もあります。
今後、検証する予定ですので、別途レポートを投稿したいと思っています。

Docker Containerの利用が広がるにつれて、すでに公開されているDocker Imageを使ったり、公式で公開されているDocker Imageから作成したDocker Imageを利用する機会が増えてくると思いますが、Docker Image自体にセキュリティ上の問題がないか、設定上にも不備がないかもチェックしていかなければならないかと思います。
脆弱性のあるパッケージの確認についてはいろいろと製品が出てきてはいますが、Vulnerability AdvisorはICPに付属している製品ですので、ぜひ試してみてください。

参考URL:

https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/manage_applications/disable_service.html

https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/installing/add_node.html

最後に

IBM Cloud PrivateのPoC環境の貸し出しも実施しています。

https://www.networld.co.jp/product/ibm-hardware/trial/

Web上にVA機能についてのPoCについて記載はありませんが、PoC環境でVAも使って検証してみたい!といったご要望がありましたら問い合わせ窓口からご相談ください。

すずきけ

Azure 上に Terraform を使って Windows Server 2019 を展開してみる

$
0
0

今回のテーマ

皆さん、こんにちは。Microsoft 担当の津久井です。

2019年を迎えてMicrosoft 関連の投稿第1回目は、Azure上で利用できるTerraformを利用して

Windows Server 2019 の仮想マシン展開までの一連の流れを試してみたいと思います。

まず本題に入る前にまずはTerraformに関する概要をご説明します。

Terraformとは

Terraformは単一のテンプレート形式言語 (HashiCorp 構成言語 (HCL)) によるコーディングに

よってインフラストラクチャー全体を構築するツールとなります。

Azureにおいてはリソースグループ、ネットワーク、ストレージなどインフラストラクチャ全体を

コードとして定義し、その内容に沿って展開できる自動化ツールとなります。

インフラ管理者は構成したいインフラの情報を記載した定義ファイルを作成します。

この設定ファイルによって作成された環境は、容易に破壊する事も出来るようになっていますので

開発や検証に必要な環境をわずかなステップで準備出来ます。

 

今回紹介する作業の流れ

 作業の流れとしては以下となります。 

・Azure Cloud Shellを利用してGithubからTerraformのサンプルファイルをダウンロード。

・サンプルの定義ファイルを元に、Windows Server2019の展開用に定義ファイルを編集。

・Terraformを実行し、仮想マシンが作成されている事を確認 

作業手順

Azure 管理ポータルにサインインし、画面右上のAzure Cloud Shell を起動します。

84

操作がしやすいよう全画面表示に変更します。

108

Github サイトの Terraform レポジトリにアクセスし、Clone&DownloadをクリックしてURLをコピーします。

372

以下のコマンドを実行しダウンロードします。

git clone  https://github.com/terraform-providers/terraform-provider-azurerm.git

480

ダウンロード完了したらサンプルファイルが保存されているディレクトリに移動します。

今回利用するテンプレートは、[vm-joined-to-active-directory]です。

684

既にテンプレート化されたファイルですので、編集せずにそのまま実行出来るのですが、今回は

Azureリージョンを「West Europe→East US」とOSバージョンを「2016→2019」に変更する

ために以下の3つのファイルを編集していきます。

今回は Cloud Shell エディターを利用してファイルを編集します。

816_2

編集の行うのは以下の3つのファイル(黄色ハイライト)となります。
Editfiles

エディタを利用しして、該当箇所を編集していきます。

main.tf ファイル内の location を「East US」に変更します。

1068

2-virtual-machine.tf ファイル内の sku を「2019 Datacenter」に変更します。

1260

編集が終わったら、「terrafom init」コマンドを実行します。

これにより Azure でテンプレートをビルドするための条件が Terraform に与えられます。

Init

続いて、[terraform plan]を実行します。これにより定義ファイルのエラーチェックならびに期待通りの結果が得られるかどうかを確認する事ができます。

今回のテンプレートでは、展開に必要な以下の3つの変数を入力します。

・admin_password:管理者パスワード
・admin_username:仮想マシンのローカルおよびADの管理者ID
・var.prefex:リソースグループ名など Azure の各リソース名のプレフィックス値となる文字列


Plan

処理を実行して良いかの確認で「yes」を入力します。

2424  

Planで問題ない事が確認出来たら、「terraform apply」コマンドを実行します。

これにより実際に処理が行われますので、あとは待つのみです。

テンプレートのREADME通り、展開には20分程で完了しました。

2844

画面ショットだけではわかりにくいかもしれませんので実際にコマンドを実行した様子を動画に

まとめていますのでこちらも併せてご覧ください。

 terraform 実行デモ動画  

動作確認

処理完了後、Azure Portalを確認してみると想定通り2台の仮想マシンが作成されました。 

Azure ポータルからリモートデスクトップで接続してみると、ドメイン参加済みのサーバー1台と、Active Directoryドメインコントローラーが正しく構成されておりました。 Image003

まとめ

今回は2台のWindows Server 2019 の仮想マシンを作成し、Active Directoryが稼働する

テンプレートをご紹介しました。

 

TerraformではAzure に限らず他社のクラウドやオンプレミス向けにも豊富なテンプレートが

用意されています。

 

Terraformを利用してシステムの一貫性を保ちつつ複数台を一気に展開する事も可能かと思います。

 

Azureでは今回ご紹介したTerrafom以外にも下記に紹介されているような自動化を支援する

ツールが利用可能となっていますのでお客様のニーズにマッチしたツールをご利用頂ければと

思います。

 

Azure の仮想マシンでインフラストラクチャ自動化ツールを使用する

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

記事担当者:津久井

  


IBM Cloud Private 3.1.1 Microclimateのインストール

$
0
0

皆さん、CI/CDツールは何を利用されていますでしょうか?
IBM Cloud Privateはエンドツーエンドの開発環境であるMicroclimateの動作環境として対応しています。

https://Microclimate-dev2ops.github.io/

Microclimate is an end to end development environment that lets you rapidly create, edit, and deploy applications. Applications are run in containers from day one and can be delivered into production on Kubernetes through an automated DevOps pipeline using Jenkins. Microclimate can be installed locally or on IBM Cloud Private, and currently supports Java, Node.js, and Swift.

IBM Cloud Private上のHelmのカタログにもMicroclimateがあるか見てみますと・・・

20190110_13h32_22a

ありました!

あるなら動かしてみよう!の精神で今回はMicroclimateをインストール(デプロイ)してみます。

 

参考URL:

https://www.ibm.com/support/knowledgecenter/ja/SSBS6K_3.1.0/featured_applications/Microclimate.html
https://github.com/IBM/charts/blob/master/stable/ibm-Microclimate/README.md

 

テストした環境

サーバーは全部で3台用意します。

  • ICP Master Server
  • ICP Worker Server
  • NFS Server

 

Master / Worker Serverのスペック

OSRedHat Endterprise Linux 7.4
物理/仮想仮想
CPU(Core)8
Memory24GB
Disk300GB
NIC1つ

 

NFS Serverの領域

Persistent Volumeとして20GB以上ご用意ください。
今回はCent OSを用意し、NFS Serverとして稼働させています。

ICP Version

ICPのバージョンは3.1.1になります。

ICPの構築

こちらを参考に構築してください。

Microclimateインストール手順概要

  1. Name Space の作成
  2. Microclimate PiplineのName Spaceの作成
  3. Cluster_CA_Domainの確認
  4. Cluster Image Policyの作成
  5. Microclimate registry secret の作成
  6. Helmで利用するSecretの作成
  7. Microclimate pipeline secretの作成
  8. Ingress Domain Name の作成(今回はHostsで逃げます)
  9. Helmからインストール
  10. Persistent Volumeの作成

github上のドキュメントでは、9.と10.が逆ですが、動きがわかりやすいようにこの順番でインストールを行っていきます。

 

 

Install !!

コマンド実行の作業はMaster Server上にSSH等でログインし実行します。

 

1. Name Space の作成

ICPではDefaultというNameSpace(ICPのGUI上では「名前空間」)が用意されていますが、Microclimate用に用意する必要があります。
GUI、コマンドどちらからでも設定できます。

NameSpace名は microclimate-space としています。

GUI

GUIから作成する場合は、ICP管理コンソールにログインし、メニューの[管理]-[名前空間]から作成します。
名前は任意となり、「ポッド・セキュリティ・ポリシー」では ibm-restricted-psp を選択してください。

コマンド

コマンドで設定する場合は以下になります。

※最初にICPクラスタにログインします。

cloudctl login -a https://<your-cluster-ip>:8443 -n kube-system --skip-ssl-validation 

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

次に作成のコマンドを実行します。

kubectl create namespace <namespace name>

今回は名前を microclimate-spaceにします。

kubectl create namespace microclimate-space

作成したNameSpaceで作業するように変更します。

cloudctl login -a https://<your-cluster-ip>:8443 -n microclimate-space --skip-ssl-validation


2. Microclimate PiplineのName Spaceの作成

1.と同様にNameSpaceを作成します。

kubectl create namespace microclimate-pipeline-deployments

名前は変えず、このまま使います。 GUIで作成する場合も同様に作成します。「ポッド・セキュリティ・ポリシー」もibm-restricted-psp で問題ありません。


3. Cluster_CA_Domainの確認

これはインストール時に決まっています。Config.yamlで特に指定していなければ、 mycluster.icpがドメインになります。

設定値はConfig.yamlに記載されています。
下記のコマンドで確認できます。

cat /opt/ibm-cloud-private-3.1.1/cluster/config.yaml | grep cluster_name
# cluster_name: mycluster
# cluster_CA_domain: "{{ cluster_name }}.icp"


4. Cluster Image Policyの作成

ICPではデフォルトで取得できるDocker.ioのイメージがポリシーで設定されています。
MicroclimateのDockerイメージを取得できるように、ポリシーを追加します。

追加する前に 既存のポリシー を確認します。

ポリシーのリストを確認

kubectl get ClusterImagePolicy

結果

NAMEAGE
ibmcloud-default-cluster-image-policy1d
 

ポリシーの詳細を確認

kubectl describe ClusterImagePolicy ibmcloud-default-cluster-image-policy

Name: ibmcloud-default-cluster-image-policy
Namespace:
Labels: <none>
Annotations: <none>
API Version: securityenforcement.admission.cloud.ibm.com/v1beta1
Kind: ClusterImagePolicy
Metadata:
Creation Timestamp: 2018-12-25T08:27:11Z
Generation: 1
Resource Version: 3254
Self Link:
/apis/securityenforcement.admission.cloud.ibm.com/v1beta1/clusterimagepolicies/ibm
cloud-default-cluster-image-policy
UID: e00ff4c7-081e-11e9-8cff-00505687010b
Spec:
Repositories:
Name: mycluster.icp:8500/*
Name: registry.bluemix.net/ibm/*
Name: docker.io/ppc64le/*
Name: docker.io/amd64/busybox*
Name: docker.io/vault:*
Name: docker.io/consul:*
Name: docker.io/python:*
Name: docker.io/centos:*
Name: docker.io/postgres:*
Name: docker.io/hybridcloudibm/*
Name: docker.io/ibmcom/*
Name: docker.io/db2eventstore/*
Name: docker.io/icpdashdb/*
Name: docker.io/store/ibmcorp/*
Name: docker.io/alpine*
Name: docker.io/busybox*
Name: docker.io/dduportal/bats:*
Name: docker.io/cassandra:*
Name: docker.io/haproxy:*
Name: docker.io/hazelcast/hazelcast:*
Name: docker.io/library/busybox:*
Name: docker.io/minio/mc:*
Name: docker.io/minio/minio:*
Name: docker.io/nginx:*
Name: docker.io/open-liberty:*
Name: docker.io/rabbitmq:*
Name: docker.io/radial/busyboxplus:*
Name: docker.io/ubuntu*
Name: docker.io/websphere-liberty:*
Name: docker.io/wurstmeister/kafka:*
Name: docker.io/zookeeper:*
Name: docker.io/ibmcloudcontainers/strongswan:*
Name: docker.io/opsh2oai/dai-ppc64le:*
Name: docker.io/redis*
Name: docker.io/f5networks/k8s-bigip-ctlr:*
Name: docker.io/rook/rook:*
Name: docker.io/rook/ceph:*
Name: docker.io/couchdb:*
Name: docker.elastic.co/beats/filebeat:*
Name: docker.io/prom/statsd-exporter:*
Name: docker.elastic.co/elasticsearch/elasticsearch:*
Name: docker.elastic.co/kibana/kibana:*
Name: docker.elastic.co/logstash/logstash:*
Name: quay.io/k8scsi/csi-attacher:*
Name: quay.io/k8scsi/driver-registrar:*
Name: quay.io/k8scsi/nfsplugin:*
Name: k8s.gcr.io/hyperkube:*
Name: registry.bluemix.net/armada-master/ibm-worker-recovery:*
Events: <none>

 

ポリシーを追加設定

まずは、yamlファイルを作成します。
ファイル名: mycip.yaml

apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1
kind: ClusterImagePolicy
metadata:
name: microclimate-cluster-image-policy
spec:
repositories:
- name: <cluster_ca_domain>:8500/* # ← ドメインを変えるのを忘れずに。
- name: docker.io/maven:*
- name: docker.io/jenkins/*
- name: docker.io/docker:*
 
作成したファイルを適用します。

kubectl create -f mycip.yaml

作成されていることを確認します。

kubectl get clusterimagepolicy
NAME AGE
ibmcloud-default-cluster-image-policy 1d
Microclimate-cluster-image-policy 23h

作成したポリシーの詳細も確認してみます。

kubectl describe clusterimagepolicy microclimate-cluster-image-policy
Name: Microclimate-cluster-image-policy
Namespace:
Labels: <none>
Annotations: <none>
API Version: securityenforcement.admission.cloud.ibm.com/v1beta1
Kind: ClusterImagePolicy
Metadata:
Creation Timestamp: 2018-12-26T02:23:52Z
Generation: 1
Resource Version: 123615
Self Link:
/apis/securityenforcement.admission.cloud.ibm.com/v1beta1/clusterimagepolicies/Mic
roclimate-cluster-image-policy
UID: 494d92d8-08b5-11e9-8c84-00505687010b
Spec:
Repositories:
Name: <cluster_ca_domain>:8500/*
Name: docker.io/maven:*
Name: docker.io/jenkins/*
Name: docker.io/docker:*
Events: <none>

5. microclimate registry secretの作成

ICP内にあるPrivate Registryを使うための認証キーを作成します。
実行するコマンドは下記になります。

kubectl create secret docker-registry microclimate-registry-secret \
--docker-server=<cluster_ca_domain>:8500 \
--docker-username=<account-username> \
--docker-password=<account-password> \
--docker-email=<account-email>

それぞれデフォルト値は下記のようになります。

変数名デフォルト値
< cluster_ca_domain >mycluster.icp
< account-username >admin
< account-password >admin
< account-email >デフォルト値なし。任意の値

環境にあわせたサンプルのコマンドは下記になります。

kubectl create secret docker-registry microclimate-registry-secret \
--docker-server=mycluster.icp:8500 \
--docker-username=admin \
--docker-password=admin \
--docker-email=admin@test.local
 

6. Helmで利用するSecretの作成

MicroclimateのデプロイにHelmを利用します。Helmを利用するのに必要な証明書を含んだSecretを作成します。

下記のコマンドで .Helm/ が見えるか確認します。 

見える場合のサンプル

ls -la $HELM_HOME

total 16
drwxr-xr-x 2 root root 51 Dec 27 10:15 .
dr-xr-x---. 10 root root 4096 Dec 26 15:16 ..
-rw------- 1 root root 2004 Dec 27 10:15 ca.pem
-rw------- 1 root root 1424 Dec 27 10:15 cert.pem
-rw------- 1 root root 1704 Dec 27 10:15 key.pem

3つの .pemファイルが表示されていない場合は、$HELM_HOMEにPathが通っているか確認します。

printenv | grep HELM_HOME

なにもリストされない場合は、Pathを設定します。
※今回は root で作業しているので下記になっています。

export HELM_HOME="/root/.helm"

再度、コマンドを実行し .pem ファイルがリストされることを確認します。

ls -la $HELM_HOME

下記のコマンドを実行して、Secretを作成します。

kubectl create secret generic microclimate-helm-secret --from-file=cert.pem=$HELM_HOME/cert.pem --from-file=ca.pem=$HELM_HOME/ca.pem --from-file=key.pem=$HELM_HOME/key.pem

 

7. Microclimate pipeline secretの作成

NameSpace "microclimate-pipeline-deployments"用のSecretも必要になりますので作成します。
実行するコマンドは下記になります。

kubectl create secret docker-registry Microclimate-pipeline-secret \
--docker-server=<cluster_ca_domain>:8500 \
--docker-username=<account-username> \
--docker-password=<account-password> \
--docker-email=<account-email> \
--namespace=Microclimate-pipeline-deployments

デフォルトの値は 5. microclimate registry secretの作成 で作成した値と同じです。

変数名デフォルト値
< cluster_ca_domain >mycluster.icp
< account-username >admin
< account-password >admin
< account-email >デフォルト値なし。任意の値

設定のサンプルは下記になります。

kubectl create secret docker-registry microclimate-pipeline-secret \
--docker-server=mycluster.icp:8500 \
--docker-username=admin \
--docker-password=admin \
--docker-email=admin@test.local \
--namespace=microclimate-pipeline-deployments

次にSecretを割り当てます。 まずは現状を確認します。

kubectl describe serviceaccount default --namespace microclimate-pipelinedeployments

Name: default
Namespace: Microclimate-pipeline-deployments
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: default-token-2qn78
Tokens: default-token-2qn78
Events: <none>

"Image pull secrets"がnone の場合は下記コマンドを実行します。

kubectl patch serviceaccount default --namespace microclimate-pipeline-deployments -p "{\"imagePullSecrets\": [{\"name\": \"microclimate-pipeline-secret\"}]}"

"Image pull secrets" に Microclimate-pipeline-secret 以外の値(別のSecret)が適用されている場合、下記のコマンドで書き換えます。

kubectl patch sa default -n microclimate-pipeline-deployments --type=json -p="[{\"op\":\"add\",\"path\":\"/imagePullSecrets/0\",\"value\":{\"name\": \"microclimate-pipeline-secret\"}}]"

適用後は下記のようになります。

kubectl describe serviceaccount default --namespace Microclimate-pipelinedeployments

Name: default
Namespace: Microclimate-pipeline-deployments
Labels: <none>
Annotations: <none>
Image pull secrets: Microclimate-pipeline-secret
Mountable secrets: default-token-2qn78
Tokens: default-token-2qn78
Events: <none>

 

8. Ingress Domain Name の作成(今回はHostsで設定します)

環境上用意が難しいので今回はHostsを使って設定します。
MicroclimateとjenkinsのWebサービス用にサブドメインを自動的につけて、80,443で通信するので、仮にドメイン名が icppoc.local だとすると、

microclimate.icppoc.local
jenkins.icppoc.local

にアクセスすることになります。
今回はデプロイ完了後に接続元PC(Windows)のhostsを書き換えてアクセスさせてしまいます。

 

9. Helmからインストール

Helmからインストールします。 ここからはGUIで操作してみます。

管理コンソールの[カタログ]に移動し、[Microclimate]で検索します。
表示された項目をクリックします。

20190110_13h32_22a_2



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

20190110_14h51_31

表示された画面で下記項目を埋めて、[インストール]をクリックします。

項目名
Helmリリース名任意の名前(microclimatetest)
ターゲット名前空間[1. Name Space の作成]で作成したNameSpaceを選択
使用許諾条件チェックする
ポッドセキュリティー入力なし
Microclimate Ingress Domain任意のドメイン

今回、任意のドメインは icppoc.localと指定します。

20190110_14h52_57 

デプロイ後、Helmリリースの情報を確認してみます。 管理コンソールのメニューから[ワークロード]-[Helmリリース]に移動します。

20190110_14h56_08


microclimate で検索し、対象のHelmリリースをクリックします。

20190110_14h56_36a


デプロイメントのステータスで”使用可能”のステータスに”1”と表示されていなかったり、ポッドのステータスが"Running"となっていない状態になっています。
また、 Persistent Volume Claim の状況が Pendingになっています。

20190110_14h56_51

20190110_14h57_50

これは、Persistent Volumeが存在しないため、Persistent Volume Claimがディスクを割り当てできず正常に動作していません。
次のステップでPersistent Volumeを作成します。

 

10. Persistent Volumeの作成

Microclimateで利用するPersistent Volume (以下、PV)が必要になります。
今回は NFS Server を用意し、NFSボリュームをPVとして利用します。

まず、現時点ではPVを請求する Persistent Volume Claim (以下、PVC) が作成されている状態になりますので、PVCのステータスを確認します。

管理コンソールのメニューで[プラットホーム]-[ストレージ]を開き、「PersistentVolumeClaim」のタブをクリックします。

20190110_15h04_01c


microclimatetest-ibm-microclimatemicroclimatetest-jenkinsというエントリがあります。

それぞれのステータスは下記のようになっているかと思います。

名前名前空間状況Persistent Volume要求アクセス・モード
microclimatetest-ibm-microclimatemicroclimate-spacePending-8GiRWX
microclimatetest-jenkinsmicroclimate-spacePending-8GiRWO

PVが[-]となっていますので割り当てがありません。
MicroclimateのHelmリリースではデフォルトでDynamic Provisioningが有効になっています。これは、PVCが作成されたときに、PVCの内容を満たすPVが存在すれば自動的に割り当てる機能になります。

今回のPVの請求内容は上記図の要求アクセスモード部分が該当しますので、請求を満たすPVを用意します。

NFS Serverの準備

今回は別途、構築済みのCentOSサーバーにNFS Serverをインストールし利用します。
NFSのパスは2つ作成しました。

NFS Server IP : xxx.xxx.xxx.159
Path1 : /nfs/microclimate
Path2 : /nfs/jenkins

PVの作成

PVを作成します。今回もGUI(管理コンソール)で作成します。
先ほど開いていた管理コンソール画面を開きます。
場所は管理コンソールのメニューから[プラットホーム]-[ストレージ]を開きます。 "PersistentVolume"のタブをクリックします。

20190110_15h19_18a

PersistentVolumeの作成をクリックします。

まず、PVC microclimatetest-ibm-microclimate用のPVを作成します。
要求 8Gi容量になります。RWXはアクセスモードでReadWriteManyになります。NFSサーバーはIPとPathが必要になりますので、Path1を使います。

今回設定する値は下記のようになります。

カテゴリ設定名設定値
一般名前任意の名前(microclimate-pv)
 容量8Gi
 アクセス・モード何度でも読み取り/書き込み
 再利用ポリシー保持
 ストレージタイプNFS
パラメーターキー1server
 値1xxx.xxx.xxx.159
 キー2path
 値2/nfs/microclimate

※記載のない設定は設定しません
※パラメーターのキーは"パラメーターの追加"で追加します。

 

次にPVC microclimatetest-ibm-jenkins用のPVを作成します。 容量8GiアクセスモードRWOです。 RWOはReadWriteOnceです。

カテゴリ設定名設定値
一般名前任意の名前(jenkins-pv)
 容量8Gi
 アクセス・モード一度だけの読み取り/書き込み
 再利用ポリシー保持
 ストレージタイプNFS
パラメーターキー1server
 値1xxx.xxx.xxx.159
 キー2path
 値2/nfs/jenkins

※記載のない設定は設定なし ※パラメーターのキーは"パラメーターの追加"で追加する

 

どちらも作成すると下記のようにPVにリストが追加されます。

20190110_15h26_32

請求の値にそれぞれ値が設定され、状況Boundになっています。
また、PersistentVolumeClaimのタブを開くとPersistentVolumeの値に作成したPV名が表示され、状況もBoundとなりますので、PVCはPVの割り当てを取得し、ストレージの割り当てが完了しました。
20190110_15h27_13

先ほど確認した際にはすべてが動作していなかったHelmリリースの情報を見に行きます。
管理コンソールのメニューから[ワークロード]-[Helmリリース]を開き、「microclimatetest」を開きます。

ポッドのステータスがすべてRunningになり、デプロイメントの使用可能のステータスがすべて1になっていることを確認します。

20190110_15h28_2620190110_15h28_34※ コンテナーがすべて作成されるまでに少し時間がかかります

 
最後にMicroclimateとJenkinsにログインしてみましょう。 今回、Domainに関して特に設定していませんので、Hostsを編集する必要があります。

管理コンソールのメニューから[ネットワーク・アクセス]-[サービス]を開き、「入口」タブをクリックします。

20190111_14h50_17

Microclimatetest-ibm-MicroclimateMicroclimatetest-jenkinsがリストされています。 それぞれ、ドメインは icppoc.local になり、サブドメインでMicroclimatejenkinsがついています。

アドレス部分が[-]となっている場合は、proxyノードのIPが使われています。 Proxyノードがどのサーバーか確認するには、管理コンソールの[プラットホーム]-[ノード]から確認ができます。
ここでは、 xxx.xxx.xxx.161 がProxyノードになります。

20190110_16h16_b

接続元のPCのHostsに下記を追記します。
 
xxx.xxx.xxx.161      microclimate.icptest.local
xxx.xxx.xxx.161      jenkins.icptest.local

設定後それぞれのURLにアクセスします。

https://microclimate.icptest.local/
https://jenkins.icptest.local/ 

Microclimate20190110_16h20_14

Jenkins20190110_16h19_54

この先はそれぞれのアプリケーションでの設定となっていきます。

もしアプリケーション開発環境として利用してみたいというユーザー様がいらっしゃれば、なんらかのPV(NFS)さえ用意できれば動きますので、ぜひ試してみてください。

最後に

IBM Cloud PrivateのPoC環境の貸し出しも実施しています。

https://www.networld.co.jp/product/ibm-hardware/trial/

Web上にNFSの用意の記載はありませんが、ご要望があればご用意はできますのでご興味のある方は是非ご連絡ください!

すずきけ

IBM Cloud Private 3.1.1 Workerを追加してみよう(x86 Linux版)

$
0
0

WorkerはKubernetesでいうところの Node になります。
Knowledge centerは下記のように説明されています。

ワーカー・ノードは、タスクを実行するためのコンテナー化された環境を提供するノードです。 要求の増加に伴い、ワーカー・ノードをクラスターに簡単に追加して、パフォーマンスおよび効率性を向上させることができます。 1 つのクラスターには任意の数のワーカー・ノードを含めることができますが、少なくとも 1 つのワーカー・ノードが必要です。

"簡単に追加"とあるのでさっそく簡単に追加してみましょう。

既存環境

VAの追加と同じ環境です。
サーバースペックは同じもので2台のサーバーがあります。

OSRedHat Endterprise Linux 7.4
物理/仮想仮想
CPU(Core)8
Memory24GB
Disk300GB
NIC1つ

Master ServerとWorker Serverが1台ずつあります。 ICPのバージョンは3.1.1になります。

以前、投稿した手順は3.1.0になります。3.1.1でも同様の手順でインストールできます。
また、この手順は3.1.0でも同様の作業内容になりますので、記載されているバイナリ名や、設定名等、 3.1.1 となっている部分は 3.1.0 と読み替えて手順を実施してください。

事前準備

WorkerやVAにするノードを準備します。
今回も既存環境と同じスペックのRHELの仮想マシンと同じものを用意します。

※Workerは x86_64 のLinuxサーバーだけでなく、Linux on Power や Linux on IBM Z でも動作させることができます。 動作環境の詳細は下記をご参照ください。
https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/supported_system_config/supported_os.html

追加するノード

追加するノードは下記になります。

Host nameIP作業ユーザー追加するノードの種類
icp-poc-workeradd1.icp.localxxx.xxx.xxx.167rootWorker

追加ノードで行う作業

追加ノードで行う作業はVAの追加と同じです。 追加するノードでは下記の事を行います。

  1. 通信ポートの確認
  2. SE Linux の無効化、Firewallの無効化
  3. /etc/hostsを設定
  4. 時刻の同期
  5. Python のインストール(の確認)
  6. Dockerのインストール
  7. (後から作業) sshサービスの再起動

通信ポートの確認

下記コマンドを実行してなにも表示されないことを確認します。
ss -tnlp | awk '{print $4}' | egrep -w "8001|8500|3306"

SE Linux の無効化、Firewallの無効化

SE LinuxとFirewallを無効化します。
SE Linuxは /etc/selinux/config をdisableに変更します。
Firewallは下記のコマンドを実行します。

systemctl stop firewalld systemctl disable firewalld

/etc/hostsを設定

クラスターに存在するすべてのノード(Master/Worker/VA/Management/Proxy)を /etc/hosts に指定します。

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 xxx.xxx.xxx.161 icp-poc-master1.icp.local
xxx.xxx.xxx.164 icp-poc-worker1.icp.local
xxx.xxx.xxx.167 icp-poc-workeradd1.icp.local

 
時刻の同期

追加するノードと既存のサーバー群と時刻の差が出ないように時刻同期を行います。
時刻同期方法は各Linuxのドキュメントをご確認ください。

RHELで時刻、時刻同期の設定の確認は下記コマンドでできます。

# timedatectl
Local time: Tue 2019-01-08 11:01:18 JST
Universal time: Tue 2019-01-08 02:01:18 UTC
RTC time: Tue 2019-01-08 02:01:17
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
 

Python のインストール(の確認)

Pythonがインストールされていることを確認します。

# python --version
Python 2.7.5

サポートされているPythonのバージョンは、2.6,2.7,3.5以上になります。

Dockerのインストール

Dockerをインストールします。DockerのバイナリーはIBM社から提供されています。

  • IBM Cloud Private 3.1.1 Docker for Linux (x86_64) (CNXD2EN )
    size: 141MB

このファイルをノード上にコピーし実行します。

cd /(ファイルをコピーした場所) ./icp-docker-18.03.1_x86_64.bin --install

※このとき、内部で別のコンポーネントをyumでインストールします。

dockerが自動起動されるように設定します。

systemctl start docker
systemctl enable docker

(後から作業) sshサービスの再起動

既存のMaster ServerからSSH Keyをコピーした後にSSH Serviceの再起動を行います。
後述の手順内で再度ご案内します。


Master Serverで行う作業

実際のインストール作業については既存のMaster Serverから行います。

  • SSH Keyのコピー
  • (後から作業) sshサービスの再起動
  • バイナリーファイルの確認
  • Workerの追加

SSH Keyのコピー

Master Server上からノードにSSH Keyをコピーします。

ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<node_ip_address>

今回は、下記の情報を使ってコマンドを実行します。

usernode_ip_address
rootxxx.xxx.xxx.167
ssh-copy-id -i ~/.ssh/id_rsa.pub root@xxx.xxx.xxx.167

!!!ノードで作業!!! sshサービスの再起動

ノード上でSSH Serviceを再起動します。

systemctl restart sshd 

バイナリーファイルの確認

下記にLinux用のバイナリーファイルがあることを確認します。
インストールパスを変更している場合は適宜読み替えてください。

PathFile name
/opt/ibm-cloud-private-3.1.1/cluster/imagesibm-cloud-private-x86_64-3.1.1.tar.gz

コマンド

# ls /opt/ibm-cloud-private-3.1.1/cluster/images
ibm-cloud-private-x86_64-3.1.1.tar.gz

Workerの追加

Workerの追加は下記のコマンドを参考に実行します。

docker run -e LICENSE=accept --net=host \
-v "$(pwd)":/installer/cluster \
ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee worker -l \
ip_address_workernode1,ip_address_workernode2

IPアドレス xxx.xxx.xxx.167 をWorkerとして追加しますので、実行するコマンドは下記になります。

cd /opt/ibm-cloud-private-3.1.1/cluster
docker run -e LICENSE=accept --net=host \
-v "$(pwd)":/installer/cluster \
ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee worker -l \
xxx.xxx.xxx.167

これでWorkerの追加は完了です!追加の流れはVAの追加とほとんど変わりません。VAの追加よりも簡単です。
事前準備さえできればすぐ追加できます。

次に本当に追加されているかと動作を簡単に確認してみたいと思います。

管理コンソール上での確認

管理コンソールのメニューから[プラットホーム]-[ノード]とたどっていただくと登録されているノードが表示されます。
ここでWorkerとして追加したノードが表示されていることを確認できます。

20190111_17h21_59a

動作確認

次に実際にPodが追加したWorker上にスケジュール(動作)するか確認してみます。
※ KubernetesではPodのスケジューリングはWorker上の負荷を考慮して自動的に行われます。
このテストでは新しいWorkerに配置されてほしいので、Podが特定のWorkerに配置されるように仕込みをしたyamlファイルでデプロイします。

ラベルの作成

追加した Worker にラベルを付与し、そのラベルをもつWorkerに対してPodをデプロイするように指定します。

ICP MasterサーバーにSSHでログインし、Kubernetes Clusterにログインします。

# cloudctl login -a https://mycluster.icp:8443 --skip-ssl-validation
Username> admin
Password>
Authenticating...
OK
Targeted account mycluster Account (id-mycluster-account)
Select a namespace:
1. cert-manager
2. default
3. ibmcom
4. istio-system
5. kube-public
6. kube-system
7. microclimate-pipeline-deployments
8. microclimate-space
9. platform
10. services
Enter a number> 6
Targeted namespace kube-system
Configuring kubectl ...
Property "clusters.mycluster" unset.
Property "users.mycluster-user" unset.
Property "contexts.mycluster-context" unset.
Cluster "mycluster" set.
User "mycluster-user" set.
Context "mycluster-context" created.
Switched to context "mycluster-context".
OK
Configuring helm: /root/.helm
OK

※クラスター名を mycluster.icpから変更している場合は変更した値で実行してください。

Workerのリストを確認します。

# kubectl get nodes
NAMESTATUSROLESAGEVERSION
xxx.xxx.xxx.161Readyetcd,management,master,proxy5dv1.11.3+icpee
xxx.xxx.xxx.164Readyworker5dv1.11.3+icpee
xxx.xxx.xxx.167Readyworker3dv1.11.3+icpee

追加したWorkerは xxx.xxx.xxx.167 になりますので、このNodeに対してラベルを付与します。
付与するラベルは workertest=deploy としています。

# kubectl label node xxx.xxx.xxx.167 workertest=deploy

ラベルを確認します。

# kubectl -L=workertest get nodes
NAME  STATUSROLESAGEVERSIONWORKERTEST
xxx.xxx.xxx.161Readyetcd,management,master,proxy5dv1.11.3+icpee 
xxx.xxx.xxx.164Readyworker5dv1.11.3+icpee 
xxx.xxx.xxx.167Readyworker5dv1.11.3+icpeedeploy

xxx.xxx.xxx.167 にラベルの値 deploy が付与されていることを確認します。

yamlファイルの作成

次にyamlファイルを2つ作成します。

  • ファイル名 : test-all.yaml
  • ファイル名 : test-add_only.yaml

それぞれの用途は下記になります。

ファイル名用途
test-all.yamlすべてのWorkerを対象としてPodをデプロイ
test-add_only.yaml追加したWorkerに対してだけPodをデプロイ

この2つのYamlを使って、追加したWorkerが利用できることと、既存のWorkerと一緒に動作し分散されることを確認します。

test-all.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: allnode-deployment
  spec:
    replicas: 5
    selector:
      matchLabels:
        app: allnode
    template:
      metadata:
        labels:
          app: allnode
      spec:
        containers:
          - name: nginx-container
            image: nginx:latest
            ports:
              - containerPort: 80

test-add_only.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: workeraddtest-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: addworkeronly
  template:
    metadata:
    labels:
      app: addworkeronly
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          ports:
            - containerPort: 80
      nodeSelector:
        workertest: deploy

deploymentの作成

yamlファイルからDeploymentを作成します。

NameSpace(名前空間)を default に変更します。

# cloudctl login -a https://mycluster.icp:8443 -n default --skip-ssl-validation

Username> admin
Password>
Authenticating...
OK
Targeted account mycluster Account (id-mycluster-account)
Targeted namespace default
Configuring kubectl ...
Property "clusters.mycluster" unset.
Property "users.mycluster-user" unset.
Property "contexts.mycluster-context" unset.
Cluster "mycluster" set.
User "mycluster-user" set.
Context "mycluster-context" created.
Switched to context "mycluster-context".
OK
Configuring helm: /root/.helm
OK

PodやDeploymentが存在しないことを確認します。

# kubectl get deployments
No resources found.
# kubectl get pods
No resources found.

追加したWorkerにデプロイ

追加したWorkerにだけデプロイするyaml (test-add_only.yaml)をデプロイします。

# kubectl apply -f test-add_only.yaml
deployment.apps/allnode-deployment created

Deploymentが作成されていることを確認します。

# kubectl get deployment

20190115_14h27_35

Podを確認します。

# kubectl get pods -o wide

20190115_14h28_19a

NODEの値がすべて xxx.xxx.xxx.167 となっており、すべてのPodが追加されたWorker上で動作しています。

すべてのWorkerにデプロイ

最後にデプロイするWorkerを指定していない yamlファイルからDeploymentを作成し、ICPが自動でWorkerを分散してPodを作成することを確認します。

# kubectl apply -f test-all.yaml
deployment.apps/allnode-deployment created

Deploymentが作成されていることを確認します。

# kubectl get deployment

20190115_14h29_35

Podを確認します。

# kubectl get pods -o wide

20190115_14h29_52a_2

allnode-で始まるPodがすべてのWorkerにデプロイする設定としたPodです。
NODEの値に xxx.xxx.xxx.164 がありますので、既存であったWorkerと追加したWorkerどちらも利用してデプロイしていることが確認できます。

今回は以上になります。
後半の動作確認でいくつか実施していることがありますが、Workerの追加だけであればかなりシンプルに実施できることを実感していただけるかと思います。

動作確認で利用したyamlファイルは下記になります。  

(毎度の)最後に

IBM Cloud PrivateのPoC環境の貸し出しも実施しています。

https://www.networld.co.jp/product/ibm-hardware/trial/

Worker追加用の仮想マシンの用意もできますのでぜひぜひご利用ください。

すずきけ

Calm .NEXT 要約: クラウドマイグレーション, Kubernetes,等々

$
0
0

55e2617be281476786924e1f1c1ea7a6_th

本記事の原文はもともとNutanix社のVP,Engineering のVishal Sinha 氏によるものです。

原文を参照したい方はCalm .NEXT Recap: Cloud Migration, Kubernetes, and More!ご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


先日 数千人ものITプロフェッショナルの方々が ヨーロッパで開催された.NEXT へ集まりました。

もし見逃していても心配しないでください。本日はお客様がキャッチアップできるように主要なCalm、関連するセッションの要約をプレゼンテーションのリンクと動画紹介します。

キーノートでのCalm: App Mobility デモ

オープニングキーノート良かったものを選択するのは難しいですが、Calm, Xi Beam , Xtractはスタイリッシュに締めくくりました。最高のデモの中で私たちはどのようにBeamが非効率を無駄な投資を識別しCalmを利用したAHVへの移行も含め改善方法を推奨してくれます。

0e10b2ce0a974b56b7b632c2a1a33a2e

Calm はアプリケーションプロファイルを利用して移行を実施し、移行中はCalmはシームレスにXtractを利用してデータのコピーを行います。カットオーバーを実施する際は、CalmはXtractを利用してNutanix CBTドライバを利用して最終変更の差分をコピーします。

3b87873e6b4148938672417b6fbde46d

App Mobilityは以前開発段階ですが、これは私たちがオンプレミスの専門知識とマルチクラウド管理のポートフォリオによる解除できるたくさんの可能性の内の1つでしかありません。

これがら利用可能になった際には追加の情報と共にお知らせしますのでそれまでお待ちください。


 
 
 

ブレークアウトセッション

キーノートは未来の可能性を理解するのには素晴らしい場所ですですが、私たちが今日何が利用できるを深くしる事ができるのはブレークアウトセッションです。私たちは既にすべてのブレークアウトセッションをこちらに投稿しています。4つのトラックをまたがる50以上もあるブレークアウトセッションはお客様がもっと常に知りたいと思っている事をカバーする何かがあるはずです。

特に次の4つはお客様がきっと気に入っていただけるCalm , 自動化に関するセッションです。


Automation and Multi-Cloud Management with Nutanix Calm:Calmを開始するには?

Calmとは?Calmの基礎を理解するセッションです。

Nutanix Calm In-depth and Implementation Tips:もっと多くの技術セッションを探していますか?

このセッションはこのセッションはKubernetesやJenkins Integrationのデモに注力しているのでスライドが抜けていますが、カバーするために TechTopX seriesも合わせてご覧ください。残りに関しても準備が出来次第、投稿していきます。


Cloud Native Apps with Nutanix Kubernetes (Karbon):Nutanix Karbon - 現在はTech Preview の製品です - ワンクリックでお客様のNutanix Cluster へKubernetes環境を展開する事が出来ます。こちらはCalm’s Kubernetes supportも合わせて参照頂くことでより理解を高めKubernetesを始める良い機会になります。

Nutanix Era: 1-Click Database Management: Eraはタイムマシン機能を利用しながら、素晴らしいCDMと一体化したNative データベースの提供、客様がデータベースのコピー、ロールバック、即座にデータリフレッシュを提供する事を可能しています。



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

記事担当者 : SI技術本部 カッシー @Networld_NTNX

IBM Cloud Private 全部GUIでやるOpen Libertyのテストデプロイ

$
0
0

今回はIBM Cloud Privateって構築してみたけど、アプリケーションの開発とかやらないし、この先どうしたらいいのかよくわからないな~という人のためにサクッとできるデプロイしたContainerが動作しているか確認する方法を書いていきたいと思います。
また、ポイントとしてはGUIでという部分です。ご存知の通り、ICPではKubernetesサービスが動いていますが、他のクラウドサービスとかですとコマンドベースで動かしていることが多そうです。
ただ、せっかく製品買ったし、GUIあるなら使いたい!ということでGUIをご案内します。

環境

定番の環境の情報です。
今回使ったのはICPクラスタ1台です。
作り方は IBM Cloud Private 3.1.1 インストール方法(RHEL編)で書いています!
※今回使う環境はICP 3.1.0 ですが、方法に変わりはありません。


構築する環境

2台のサーバーを使いICPをインストールします。

1台目:Master node (manager,management,etcd,proxy)
2台目:Worker node (Worker)
※インストール手順では、1台目を「Master」、2台目を「Worker」を表記します。

サーバーはどちらも同一スペックを用意しています。

  • OS : RedHat Endterprise Linux 7.4
  • 物理/仮想 : 仮想
  • CPU(Core) : 8
  • Memory : 24GB
  • Disk : 300GB
  • NIC : 1つ


デプロイするアプリケーション

今回は、OSSの Open Libertyをデプロイします。


手順概要

  1. 管理コンソールにログイン
  2. Helmカタログからデプロイするアプリケーション(Open Liberty)を選択
  3. パラメータを指定してデプロイ
  4. デプロイした情報を確認(接続ポート)
  5. Webブラウザーからアクセス確認

※ 今回、Open LibertyへのWebアクセスはHTTPで構成します。


作業手順


管理コンソールにログイン

管理コンソールにログインします。
ログインのURLは

https://(MasterサーバーIP):8443

です。

Helmカタログからデプロイするアプリケーション(Open Liberty)を選択

管理コンソール右上の カタログをクリックします。

検索部分で Libertyといれると、Web Sphere LibertyOpen Libertyが表示されますので、 Open Libertyを選択します。

20190116_14h09_17a


Open Libertyの情報が表示されますので、構成をクリックします。

20190116_14h10_05a


パラメータを指定してデプロイ

今回はテストですので、必要最低限の設定だけを行います。

  • Helmリリース名 : 任意の名前
  • ターゲット名前空間 : Default
  • ポッドセキュリティー : 入力なし
  • 使用許諾条件 : チェックをつける


設定完了後、インストールをクリックします。

20190116_15h01_15a


デプロイした情報を確認(接続ポート)

インストールをクリックすると下記のポップアップが開きます。

20190116_15h15_07


Helmリリースの表示をクリックします。
Helmでデプロイされた内容の一覧が表示されます。
デプロイ直後は稼働しきっていませんので、数分後に画面をリロードします。

20190116_15h16_21

20190116_15h16_34


正常に稼働している場合は上記の画像のようになります。
稼働しているかチェックするポイントはデプロイメント使用可能1となっていることと、Pod準備完了1/1となっていることです。
※稼働するまで少し時間がかかります。

20190116_15h16_34a


外部からデプロイしたOpen Libertyに接続するために必要な接続ポートを確認します。 サービスポートの値を確認します。

9443:30791/TCP

9443はICP内部で接続する際に使用するポートで、外部から接続する場合は 30791を使用します。

接続先のIPですが、サービスタイプ部分がNodePortになっています。
NodePortの場合はICPクラスタ内のすべてのNodeのIPアドレスとポートの組み合わせで接続ができます。
今回の環境の場合、下記の2台のサーバーがあります。

  • Master Server xxx.xxx.xxx.161
  • Worker Server xxx.xxx.xxx.164

この環境でNodePortは下記のどちらからもアクセスが可能です。

  • https://xxx.xxx.xxx.161:30791/
  • https://xxx.xxx.xxx.164:30791/


Open Libertyに接続してみる

Webブラウザからアクセスしてみます。

http://(ICPクラスター内のNodeのIP):(確認したポート)/

にアクセスします。

Open Libertyのサンプルページが表示されます。

20190116_15h25_25


  • Master Server(IP末尾161)に接続

20190116_15h25_40b


  • Worker Server(IP末尾164)に接続

20190116_15h25_48b


以上です。
ICPのHelmのカタログを使うことであっさりとOpen Libertyを動作させることができました。
IBM社が用意しているものでも数多くありますので、ぜひいろいろ試してみてください。

ICP上でWAS LibertyをガッツリつかってWebアプリケーションを使いたい方は、WAS Liberty on IBM Cloud Private 利用ガイドがIBM様からリリースされていますので是非読んでみてください。

(毎度の)最後に

IBM Cloud PrivateのPoC環境の貸し出しも実施しています。

https://www.networld.co.jp/product/ibm-hardware/trial/

すずきけ

IBM Cloud Private 3.1.1 Workerを追加してみよう(Power Linux版)

$
0
0

みなさん、こんにちは。

Workerの追加のエントリで x86 Linux版とつけていましたが、このエントリのためでした。
先日、Power 9が搭載されている Newellが納品され、Redhat Enterprise Linuxがインストールされたタイミングで、こっそり借りることができたので、ICPのWorkerとして追加してしまいました。

追加方法は IBM Cloud Private 3.1.1 Workerを追加してみよう(x86 Linux版)とほぼ変わりません。
異なる点とテスト方法についてのみ書いていきます。

追加するNewell環境

環境は下記になります。


# hostnamectl
   Static hostname: Newell
         Icon name: computer
        Machine ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
           Boot ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  Operating System: Red Hat Enterprise Linux
       CPE OS Name: cpe:/o:redhat:enterprise_linux:7.5:GA:server
            Kernel: Linux 4.14.0-49.el7a.ppc64le
      Architecture: ppc64-le

  
# python --version
Python 2.7.5  

IPアドレスは xxx.xxx.xxx.6です。

手順概要

手順の大枠はx86 Linux版とほぼ変わりません。

追加するノードでは下記の事を行います。
    1. 通信ポートの確認  
    2. SE Linux の無効化、Firewallの無効化  
    3. /etc/hostsを設定  
    4. 時刻の同期  
    5. Python のインストール(の確認)  
    6. Dockerのインストール  
    7. (後から作業) sshサービスの再起動  

    Master Serverで行う作業  
    実際のインストール作業については既存のMaster Serverから行います。  
    - SSH Keyのコピー
    - (後から作業) sshサービスの再起動  
    - バイナリーファイルの確認
    - Workerの追加 

異なる点は Power用のバイナリを用意する必要があります。

  • ICP本体
    IBM Cloud Private 3.1.1 for Power Linux LE (64-bit) Docker (CNZ4XEN )
    Size : 11,108MB

  • Docker
    IBM Cloud Private 3.1.1 Docker for Power Linux LE (64-bit) (CNXD3EN )
    Size : 108MB


Dockerのバイナリは追加するノードへのインストールで利用します。
ICPのPower用バイナリは /(installation_directory)/cluster/imagesに配置します。
下記がKnowledge Centerの情報です。

https://www.ibm.com/support/knowledgecenter/ja/SSBS6K_3.1.1/installing/add_node.html#worker

    Ensure that the installer for the platform that the new node runs on, is available in your //cluster/images directory.
    For a Linux® 64-bit node, you need the ibm-cloud-private-x86_64-3.1.1.tar.gz or ibm-cp-app-mod-x86_64-3.1.1.tar.gz file.  
    For a Linux® on Power® (ppc64le) node, you need the ibm-cloud-private-ppc64le-3.1.1.tar.gz or ibm-cp-app-mod-ppc64le-3.1.1.tar.gz or file.  
    For a IBM® Z worker node, you need the ibm-cloud-private-s390x-3.1.1.tar.gz file. 


Worker追加手順

今回は事前準備が終わった状態で、Master Server上にバイナリーファイルをコピーまでが終わった状態の想定でバイナリーファイルの確認から行います。


ls /opt/ibm-cloud-private-3.1.1/cluster/images ibm-cloud-private-ppc64le-3.1.1.tar.gz ibm-cloud-private-x86_64-3.1.1.tar.gz

Power用の ibm-cloud-private-ppc64le-3.1.1.tar.gzが配置されていることを確認します。


下記コマンドを実行し、Workerの追加を行います。
実行コマンドは x86 Linux版のときと全く同じです。

cd /opt/ibm-cloud-private-3.1.1/cluster
docker run -e LICENSE=accept --net=host \
-v "$(pwd)":/installer/cluster \
ibmcom/icp-inception-$(uname -m | sed 's/x86_64/amd64/g'):3.1.1-ee worker -l \
xxx.xxx.xxx.6 


動作確認


管理コンソール上で確認

管理コンソールのメニューから[プラットホーム]-[ノード]とたどっていただくと登録されているノードが表示されます。 ここでWorkerとして追加したノードが表示されていることを確認できます。

20190118_11h42_11a


アーキテクチャー部分が ppc64leとなっているものがPowerのノードです。


ノードの動作確認

次に実際にPodが追加したWorker上にスケジュール(動作)するか確認してみます。
x86 Linuxの場合は仕込みをして確認しましたが、今回は仕込みをせずにHelmを利用する際にパラメーターを変更して対応します。

管理コンソール右上の カタログをクリックします。 検索部分で Libertyといれると、Web Sphere LibertyOpen Libertyが表示されますので、 Open Libertyを選択します。

20190118_11h50_14a


Open Libertyの情報が表示されますので、構成をクリックします。

20190118_11h50_21


パラメータを指定してデプロイします。

  • Helmリリース名 : 任意の名前
  • ターゲット名前空間 : Default
  • ポッドセキュリティー : 入力なし
  • 使用許諾条件 : チェックをつける
  • すべてのパラメーターを開く
    • Architecture scheduling preference
      -> ppc64le scheduling preference
      -> 3 - Most preferred


20190118_11h51_57a_2


すべて入力後、インストールを実行します。


ポップアップが表示されたら Helmリリースの表示をクリックします。
Helmリリースのステータスが表示されます。
Containerの作成が完了するまで少し待ち、デプロイメント項目にリストされているデプロイメントをクリックします。
※今回であれば power-openliberty-test1です。

20190118_11h55_17a


表示された画面の ポッド部分を確認します。
ホストIPが PowerのWorker Nodeとなっていることを確認します。
この画面上では xxx.xxx.xxx.6になります。

20190118_11h56_24a


以上になります。
せっかくのPowerのWorkerですので、できる範囲で検証を公開していきたいと思っていますのでご期待ください。


ご案内

今回利用したPowerの機器(Newell)ですが、弊社の Networld ディープラーニング検証センターにて無料でご利用いただくことが可能です。

https://www.networld.co.jp/solution/ibm-hardware_nvidia_minsky/

Power8のMinskyとPower9のNewellどちらもありますので検証してみたいという方は是非ご連絡ください!もちろんIBM Cloud Private用途でなくても問題ありません!

すずきけ

再考されたPrism - 拡張と利用の為の設計

$
0
0

本記事の原文はもともとNutanix社の Senior Staff Designer であるBryan Crowe 氏によるものです。

原文を参照したい方はPrism Reimagined - Designing for Scale and Intentご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


Prism Centralはお客様がお持ちのNutanix インフラ基盤を管理するためのマルチクラウド管理ツールです。

最初に紹介したのは4年前で、この時は限定された機能と5つの管理されたエンティティタイプがありました(VMsなど) . それ以来、20を超える新しいエンティティタイプとPlanningやDRといった素晴らしい機能を紹介してきています。

さらに、お客様は多くのホスト、クラスタと仮想マシンを一つのPrism Centralから管理する事が出来るようになります。この機能により拡大するインフラはPrism Centralは元々のデザインである拡張限界に達したため、Prism Centralの方向性を再考慮する事になったのです。


Approach

スケール行う上でサーチ機能は非常に強力な機能であり、階層化を平らにし効率を高める事を容易にしてくれます。例えばmacOSのスポットライト機能、なかでもユーザが変更したい名前を変更(例えばDisplayなど)そしてそこへ直接行けることが出来るようになり、これはとても強力で私たちがPrismの方向性を設計する上でいくつか考慮したのです。


私たちの調査ではデータセンター管理者は検索機能を利用する事に興味をある方とクリックベースのメカニズムに興味のあるが混在しています。また、サーチ機能はいくつかの基礎となる構文、ユーザにすぐに解らない構造である以上、発見と学習のいささかチャレンジとなります。

私たちの調査、繰り返し設計するプロセスに基づき、次の目的に立っていする為のアプローチへとたどり着きました。

  • スケールを考慮した強力な検索機能の提供
  • 直感的なクリックベースの発見と学習
  • 検索とクリックベースのインタラクションの結合によりユーザが容易にそれらの変更と、最適なメカニズムの利用が出来ます。
  • カスタム化のサポートでユーザは簡単に知りたい情報を簡単に入手できます

Design

このセクションでは新しいインターフェースとその機能のツアーをご体験頂きます。

7a7eeda5173343238f383fcaa15307a7

Prism Centralのメインメニューはおなじみのダッシュボードです

Note:左のヘッダ部分は検索バーとナビゲーションメニューの為、クリーンアップされています。

Afec6dd5a1554129959139860b5b867d

グローバルナビゲーションはVMなどのページへ移動するために利用する事が出来ます

4889e7a6f7884e7aae9a77576847a731

VMサマリーページは様々な情報を教えてくれます。

54d92b4ef5bb423dbc0f3e5cf5ac0815

システムのホストを見つけるために、グローバルナビゲーションへ戻り検索を使うだけでホストを見つけることが出来ます。

54d92b4ef5bb423dbc0f3e5cf5ac0815_2


ホストサマリーページはVMサマリーページと同じように確認できます

Hostsummary

もしクラスタのアラートを確認したければ、検索で"cluster alerts"と入力するとClusterのアラートを確認できるのです。

Cluster_alert

これはオートコンプリートを最初にクリックしたときのスクリーンショットです。


さらに素晴らしいフィルタークエリーもあります。例えばiopsが50以下の全てのVMを次の画像のように入力すると確認できるようになります。

Performanced

オートコンプリートはフィルターを認識し理解するための特別なフォーマットを利用します。

他の面白い例ではAHVで稼働している電源がONの仮想マシンであったり、パフォーマンスでクリティカルアラートがあるものを入力する事も出来ます。

管理者はまたシステムの全てのエンティティ(例えば VM , Host , Security , Policy)などを名前による単純な検索か関連のあるIPアドレスを入力できます。


Vm_host

これは前のクエリーを追加したVMページの状態です。

特定のフィルターが適用された仮想マシンだけを見つけることが出来るようになります。



Vms

頻繁に使うビューに関してはブックマーク登録すると簡単にアクセスできるようになります。

Photo

グローバルメニューを再度開くとブックマークした項目が上部に表示され、これにより最も頻繁に訪れているページへ簡単にアクセスできます。

前の例ではこれらのブックマークいくつものフィルターを追加しています。今のサンプルでは

管理者は異なる観点(例えばDev, Test , Production)から異なるオプションを追加する事で簡単に見ることが出来るようになるのです。

これらカテゴリ機能はサーチ機能でサポートされこのようはビューを作成し利用する事が出来るのです。


Launguage

新しい検索機能は管理者が変更したい設定項目へ簡単に移動する事も出来ます。

例えば言語設定ですが、これはグローバルナビゲーションでPrism Central設定を選択しすべてのリストを見ることが出来ます。

サマリー

PrismCentralのような近代的なWebアプリケーションはより豊富に多くの機能をサポートするようになります。インフォメーション構造とナビゲーションメカニズムはより複雑になり、検索は大量のコンテンツをナビゲーションを通して確認する一般的な方法ですが、サーチ機能を習得する事は難しい事でユーザーによってはクリックしてから検索しています。

検索とナビゲーションの統合をシームレスにしクリックベースのナビゲーションが維持されます。

より効率の良いコンテンツへのアクセスが出来るようになった一方、この新しいアプローチで従来のクリックベースの対話は管理者がサーチを通して様々な事を確認し結果的にその機能を学ぶことができます。この方法でクリックベースのナビゲーションは検索をしたくない人に親しみのある経験を提供するだけでなく、全てのお客様が理解し、学び、検索の振る舞いを受け入れる自然な方法をも提供します。

これらは皆様の異なるプロトタイプからのフィードバックによるお陰なのです。

5.10へ搭載するための追加のフィードバックも私たちは楽しみにしています。

より多くの検索機能の詳細を知りたい場合はPrism Central 5.10以降でグローバル検索マークで"Learn about search"と入力するか、シンプルに"Search Guidelines"と入力してみてください。



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

記事担当者 : SI技術本部 カッシー @Networld_NTNX

全てのNutanix AOS Clusterへ1TB容量のNutanix Files ライセンス

$
0
0

本記事の原文はVice President and GM of Nutanix FilesであるDave Kresse 氏によるものです。

原文を参照したい方は1 Free TB of Nutanix Files capacity with every Nutanix AOS clusterご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


Nutanix Filesが1TBまでAOSを合わせてご利用できるようになります。

全てのデータはセンターはファイルストレージをつかっています。Nutanix Filesを無償でつかってみませんか? NutanixFilesはNutanixが現代データーセンターにおける多くの課題を解決するためのシンプルでフレキシビリティでさらにインテリジェントなファイルストレージとなります。

そして、なんとNutanix AOSをご利用の方はAOSのCluster毎に1TBのFreeライセンスを入手できます!このことでNutanix AOSをお持ちの方はNutanixの環境へ素晴らしいファイルストレージソリューションを確かめることが出来るチャンスです!

少ないワークロードへ対しては十分ではないでしょうか

Nutanix Files って??

Nutanix FilesはNutanixの革新的なHCIプラットフォーム上に構成され、お客様のファイルストーレジのストレージ、ネットワーク、コンピュートの枠をなくします。

  • Nutanix Filesはシンプルです!それは1-クリックによる展開、プロビジョニング、NutanixPrimsで行えるシングル管理によって複雑性を排除するからです。
  • Nutanix Filesはフレキシブルです! それは多くの異なるハードウェアへ展開できますしノード、仮想リソースの追加を無停止する事でスケールアウト・スケールアップをを実現します。これだけではなく異なるタイプのストレージ(Files ,Object , Block)も同じ基盤へ展開できるのです。
  • Nutanix Filesはインテリジェンスです!リコメンデーションエンジンにより問題が発生する前にパフォーマンス、冗長化リスクを識別し1-クリックでどの様にすれば良いかを教えてくれるのです。

なんで1TBの容量が使えるのですか?

NutanixはNutanix Filesのフリーの1TBのライセンスをAOS Clusterの一部として提供します

(Nutanix Files Pro や追加機能は含まれません)

ライセンスの有効期限は?

これはお試し版ではありません。Nutanix AOSクラスタと同じ期間 Nutanix Files のライセンスを利用できます。

サポートは?

Nutanix AOS サポート契約により1TBのNutanix Files キャパシティはサポートされます。

 

どうやって利用するのですか?

既に1TBのCapacityライセンスがあります。AOSをご利用でしたらこの容量に対して何か有効にする必要もありませんので、Nutanix Filesを展開してセットアップすれば利用できます。

1TB以上のファイルストレージが必要になったら?

Nutanix Filesは既に利用可能な製品でAOSクラスタの一部として容量か専用のクラスタで利用できます。追加のサイズが必要となれば、キャパシティライセンスを購入し展開しているNutanix Filesを拡張する事が出来ます。

Mixed クラスタにNutanix Files Proを展開できますか?

いいえできません。

1TBのキャパシティはMixed Clusterで利用され、Nutanix Files ライセンスとなります。

Nutanix Filesは2つのライセンス体系となり、Nutanix Files , Nutanix Files Pro です。

Nutanix Files はmixed Cluster となりますが、Nutanix Files Proはファイルストレージ専用で構成するNutanix Clusterのライセンスとなり他のライセンス製品などを展開する事は出来ません。



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

記事担当者 : SI技術本部 カッシー @Networld_NTNX


IBM Cloud Private 3.1.1 AD連携機能を試してみる

$
0
0

みなさん、こんにちは。

今回はユーザー連携部分のお話です。
当然、この手の製品の管理コンソールですとユーザーの作成はローカルとLDAPと連携する方法があり、ICPも同様です。

LDAP連携機能では、多くの皆さんが使われているであろう Microsoft Active Directoryとの連携も対応していますので、ちょっとセットアップしてみたいと思います。

環境

ICP環境は前回、前々回などと同じ環境です。
- ICP Master server 1台
- ICP Worker server 1台

今回はActive Directoryと連携するので、下記のActive Directoryを用意しています。

AD 環境

20190131_14h28_03_2


Active Directory ユーザーとコンピューターの画面はこのようになっています。

20190129_17h32_37


今回のゴール

下記のことができるように確認します。

  1. OU=icp のユーザーが ICPのユーザーとして登録できること
  2. ADのセキュリティグループ icpgroupに所属しているユーザーでログインができること
  3. 登録したユーザーには特定のリソースしか表示、利用できないこと

ADを登録

ICPでのLDAPの登録は管理コンソールからできます。

管理コンソールにログインして、

20190129_17h36_35


メニューの[管理]-[IDおよびアクセス]に移動します。

20190129_17h36_45


接続の作成をクリックします。

20190129_17h37_07a


下記の内容を参考に設定します。
LDAP認証の部分は Distinguished Name(DN)で書く必要があります。

20190131_14h28_15


20190129_18h00_45s


DNがわからないという方は、下記のようにコマンドプロンプトから確認したユーザーを入れてみてください。

20190129_18h24_06


入力後、接続の確認をして、保存します。

チームの登録

次にチームを登録します。
チームに対して、AD上のユーザーやセキュリティグループを割り当てたり、利用可能なリソースの割り当てを行います。

メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。
チームの作成をクリックします。

20190129_18h25_20


ポップアップウインドウで下記を参考に入力します。

20190131_14h28_25


20190130_10h49_32


作成をクリックします。
チームが登録されることが確認できます。

チームに登録されているセキュリティグループの確認

さきほどのチーム登録時に指定したセキュリティグループicpgroupが登録されていることと、グループに登録されているユーザーもICP上で確認可能か見てみます。

管理コンソールで作成したチーム名をクリックします。
今回であれば、icp-teamです。

20190129_18h49_14


チームに登録されているグループの一覧が表示されます。
まだ1グループしか登録していないので、icpgroupのみが登録されています。
icpgroupをクリックします。

20190129_18h50_51


icpgroupに所属しているユーザーの一覧が表示されます。

20190130_10h52_36


セキュリティグループに登録されているユーザーのログイン確認

セキュリティグループに登録されているユーザーもICP上で確認できましたので、そのユーザーでICP管理コンソールにログインできるか試してみます。

今開いている管理コンソールをログオフするか、別の種類のWebブラウザまたはシークレットモードで起動したWebブラウザを起動します。
※あとの工程上、ログオフせずに別のWebブラウザまたはシークレットモードのWebブラウザのほうが都合がよいです。

ログイン画面で先ほど確認したセキュリティグループに登録されているユーザーでログインします。
今回は user2を利用します。

20190130_10h53_32


ログインでエラーがでることもなく、管理画面のようこそ画面が表示されることが確認できます。

20190130_10h57_13


チームにADユーザーを個別に登録

次に、作成済みのチームicp-teamにADユーザーを個別に登録してみます。

ICP管理コンソールを開き、adminでログインします。
メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。
その後、icp-teamに移動し、ユーザータブを表示します。
ユーザーの追加をクリックします。

20190130_10h57_45


下記を参考にユーザーを検索します。

20190131_14h30_18


検索結果が表示されていますので、今回はuser3を選択します。
このユーザーはセキュリティグループicp-teamには登録されていないユーザーです。
役割のカラムで役割をドロップダウンリストから選択できます。今回は管理者のまま、追加をクリックします。

20190130_10h58_27


ユーザーの一覧画面が表示され、ユーザー登録が完了していることが確認できます。

登録したユーザーでログインしてみる

登録したユーザーでICP管理コンソールにログインできるか確認してみます。

今開いている管理コンソールをログオフするか、別の種類のWebブラウザまたはシークレットモードで起動したWebブラウザを起動します。
※あとの工程上、ログオフせずに別のWebブラウザまたはシークレットモードのWebブラウザのほうが都合がよいです。

先ほど登録したuser3でログインします。

20190130_11h38_54


ログインでエラーがでることもなく、管理画面のようこそ画面が表示されることが確認できます。

20190130_11h39_08


リソースを見てみる

せっかくなので、user3で操作できるリソースを見てみます。

20190130_15h20_23


名前空間(name space)が割り当てられていないので操作ができません。
チームに対してリソースの割り当てを行います。

管理者アカウントでICP管理コンソールにログインし、メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。
その後、icp-teamに移動し、リソースタブを表示します。
リソースの管理をクリックします。

20190131_11h48_10


リソースの管理画面が表示されます。 今回は defaultibm-chartsにチェックを付け、保存します。

20190131_11h49_33

20190131_11h58_36


再度、user3でICP管理コンソールにログインします。
メニューの[ワークロード]-[デプロイメント]を開きます。

20190131_13h46_04


先ほどとは違い、エラーは表示されません。
実際にリソースが利用できるか確認してみます。
管理コンソール右上のカタログをクリックします。

20190131_13h46_04_2


検索画面に libertyと入力し、表示された結果から ibm-open-libertyを選択します。

20190131_13h46_36


構成をクリックし、下記のパラメーターを入力します。

20190131_14h28_58


記載のない設定は変更せず、インストールをクリックします。

20190131_13h55_14


Helmリリースの表示を開き、少し時間をあけてステータスを確認します。
デプロイメントのステータスの使用可能1になっており、ポッドのステータスもRunningになっていることが確認できました。

20190131_13h56_56


20190131_13h57_10


先ほどのHelmカタログからデプロイする際のターゲット名前空間のドロップリストはDefaultだけになっていましたので、user3ではdefault以外の名前空間のリソースに対しての権限を持っていないことも確認できました。

以上がAD連携の連携後の簡単な動作確認の方法でした。

NameSpace(名前空間)ごとに割り当てチームを決めることで、別のチームのNameSpaceへの影響も抑えられますし、そもそもユーザー管理をICP上でコツコツやるのは大変!という要望にもこたえられるかと思いますのでぜひ試してみてください。

現状の挙動として、ちゃんとAD上に存在していて、ICP上のチームに登録されているセキュリティグループにも所属しているADユーザーでもログインできない場合は、一度ICP上のADの登録画面で対象のADを編集で開き、再度保存してみてください。

今回も長々とありがとうございました。

すずきけ

最大のパフォーマンスをAHVとOpen vSwitchから

$
0
0

本記事の原文はであるNutanix Communityに投稿されているAHVのOpen vSwitchの基本に関する記事の翻訳です。

投稿されてから時間はたっていますが、AHVを構成する際にベースとなる構成の為、改めて紹介していきます。

原文を参照したい方はMaximum Performance from Acropolis Hypervisor and Open vSwitchご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


763i74215f1c55a62e72

Nutanixではデータネットワークをストレージのバックプレーンとして利用し、次の事がお客様がAHVを利用する上でAHVがデータセンターネットワークに接続するための良い方法なのかを決められる事を目的としています。

いくつかのバックグランドから始めましょう。AHVはOpen vSwitch(OVS)はCVM、HypervisorとゲストVM、物理ネットワークが接続されています。

OVS のサービスは各AHVノードで稼働し、OVSのサービスは自動的に起動します。

このブログはAHVの一部の内容であり、Open vSwitch BridgeとBondsの内容を包括しています。

来週のパートではロードバランス、VLANとAcropolisの管理ネットワークに触れていきますので、是非来週もご覧ください(できれば翻訳しようと考えてます)

OVS内の、bondのポートはAHVホストの物理インターフェイルにありデフォルトではbond0と名前がづけられbr0が作成されます。

(現在の最新のAOS 5.10ではボンド名はbr0-up , Bridge名はbr0となりますのでご注意ください)

ノードのイメージング(初期化)が完了したとは全てのインターフェスは一つのbondへ設定されます。これはFoundation Imagingプロセスの要件となります。

次のダイアグラムはイメージング直後の1ノードのネットワーク構成となります。

763i74215f1c55a62e72_2

次にnu.schoolのVideo(youtube動画)でデフォルトの構成についてもっと多くの事を学ぶとことが出来ます。デフォルトの設定を変更するためのコマンドやacli,cli toolについてのいくつか参考になるものも見つけることが出来るでしょう


YouTube: Tech TopX: AHV Host Networking [Part01]

大事なポイントはNutanixのCVMは10Gbアダプタに設定する事です(今では40Gbもあります)

これで最大のBandwidthと低いレイテンシーの実現をCVMへ提供するのです。それに加えてUser VMによって物理トラフィックを分けたいと思う事もあるかも知れません。

このネットワークを分離する事はセキュリティポリシー、仮想マシンのネットワーク(例えばルーティング、FireWall,ロードバランス)などによって必要になるかもしれません。

これはAHV OVS構成の推奨で1GbのNICを使った新しいブリッジの作成です。

764id82d1e145f720178

推奨の構成は10Gと1Gのインターフェイスを別々のBondへ構成し、CVMとUserVM通信は常に最速のLinkを使います。

ここでは10G(eth2, eth3)はbond0(br0-up)へグループし、CVMとUser VM1 へ

1GのインターフェイスはBond1へグループしUser VM2で利用します。

bond0とbond1はそれぞれブリッジ (br0 , br1)へ追加します。

この構成ではCVMとUser VMは10Gbのインターフェイスを利用し ブリッジ br1はCVMとbr0にいるVMから物理的にネットワークを分ける必要がある仮想マシンの為に利用できるようになります。

Eth0 , Eth1はさらに別のアップリンクのスイッチへ接続して分離する事も出来ます。

2つの上位スイッチはそれぞれのbondのインターフェイスのペアが接続し、bondの中では一つのインターフェイスがアクティブとして動作します。これはデフォルトのActive-Backup モードを利用した際の動作です。

ロードバランスについては次週に記載します。

Nutanix Clusterの各ノードで次を実施し、各Acropolis hostでブリッジbr1を追加、ローカルのAcropolis Hypervisor へはCVMから192.168.5.1 に対して接続できます。

CVMへログインしブリッジ br1を作成】

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl add-br br1"

CVMからeth0 , eth1 をすべてのCVMのデフォルトのbr0から削除します。

これらのインターフェイスはeth2 , eth3をBridgeに残して削除されます。「10g」は全ての10g インターフェイスを指定する事になります。(もちろんeth2,eth3のようなインターフェイス指定も可能です)

【br0へ10Gのみを追加する場合]

nutanix@CVM$ manage_ovs --bridge_name br0 --bond_name bond0 --interfaces 10g update_uplinks

ー>現在のデフォルトの--bond_nameはbr0-upとなります

【br0へeth2,eth3のみを追加する場合]

nutanix@CVM$ manage_ovs --bridge_name br0 --bond_name bond0 --interfaces eth2,eth3 update_uplinks

ー>現在のデフォルトの--bond_nameはbr0-upとなります

eth0とeth1をbr1へ追加する方法、「1g」のインターフェイス指定をすることも可能です

【br0へ1Gのを追加する場合]

nutanix@CVM$ manage_ovs --bridge_name br1 --bond_name bond1 --interfaces 1g update_uplinks

今や、1gbのインターフェイスが存在するbr1が存在しています。

aCLIコマンでUser VM2の為のネットワークを作ることができます。

PrismのGUIからネットワークを確認する際にブリッジ名とネットワーク名は役に立つのでここは名前を解りやすくしましょう

[cvmからbri1へvlan 99を作成、登録するコマンド]

nutanix@cvm$ acli net.create br1_vlan99 vswitch_name=br1 vlan=99

これで一つのAHVとCVMが10Gを通して接続する事が出来るようになり、User VMは10G か1Gかに接続する事が出来るようになりした。上にのせているyoutubeも参考になるので、ご参照ください。

 

ここでさらに便利なコマンドをご紹介!

ブリッジの作成などは全てのCVMに対して実施する必要がありますが、Nutanix Cluster全体のCVMはAHVへコマンドを投げることも出来ます。

全てのCVMへCLIを実施するには allssh、全てのAHVでCLIを実施するにはhostsshです。

この辺りをうまく利用しAHVの管理性を高めてみてはいかがでしょうか

Screenshot_14

記事担当者 : SI技術本部 カッシー @Networld_NTNX

Acropolis Hypervisorのネットワークロードバランス

$
0
0

本記事の原文はであるNutanix Communityに投稿されているAHVのOpen vSwitchの基本に関する記事の翻訳です。

投稿されてから時間はたっていますが、AHVを構成する際にベースとなる構成の為、改めて紹介していきます。

原文を参照したい方はNetwork Load Balancing with Acropolis Hypervisorご確認ください。

情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。

(初回はID、パスワードの取得が必要です)


763i74215f1c55a62e72_2

Acropolis Networkingの最初の記事でブリッジとbondについてお話ししました。

今回は物理ノードにおける複数のネットワークの利用方法について説明します。

771i19a614e729de5917_2


ブリッジを分けることでCVM通信は10Gbインターフェイスでルートされ、ユーザVMは10Gbか1GbのAdapterを利用してトラフィックが流れます。

OVS bond内におけるロードバランスに対する準備が出来ました。

主に考慮しないといけないのはフォールトトレランスとスループットです。

フォールトトレランスの為には上記の図のように最低でも2つのNICを利用する必要があります。

一度ボンドが2つ以上のネットワークで構成されると、一つのbondで提供されるスループットを管理できるようになります。次の全てのbondモードはフォルトトレランスを実現しています。

このビデオではAcropolis HypervisorとOpenvSwitchにおけるロードバランスの違いを説明しています。是非、nu.schoolを確認してみてくださ。

このビデオには"allssh"などbondの構成に便利なショートカットも紹介しています。


BondモードではBond内のトラフィックは複数の物理インターフェイスで分散されます。

デフォルトのモードはActive-Backupでbond内の1つのActiveリンクのみを利用し他のインターフェイスはActive Linkが落ちるまで利用されません。

BondモードとActive なインターフェイスを確認するには次のコマンドで確認できます。

nutanix@CVM$ ssh root@192.168.5.1 "ovs-appctl bond/show"

デフォルトのコンフィグのActive-Backupです、結果は次のものと近いもにになるでしょう。

---- bond0 ----
bond_mode: active-backup
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
lacp_status: off

slave eth2: enabled
active slave
may_enable: true

slave eth3: enabled
may_enable: true

Active-Backup

Active-Backup bond モードはシンプルで簡単に上位スイッチに追加の設定なしに接続できる方法です。

サーバ側の全てのVMのトラフィックはBond内の一つActiveなリンクだけを使います。。

全てのBackup linkは利用されないままです。

10Gbの2つのインターフェイスがある場合、最大のスループットは全ての仮想マシンで10Gbpsとなります。

772i377649a697233636_2


Active-backupモードはデフォルトで有効ですが、AHVで次のコマンドを実行し構成する事も出来ます。

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 bond_mode=active-backup"


Balance-slb

複数の上位スイッチのリンクの利用により帯域幅を有効活用できます。

私たちはこのbalance-slbのモードの利用を推奨します。

このOVSのbalance-slb モードはBond内の全てのリンクを利用し、トラフィックを測定して仮想マシンをトラフィックの多いインターフェイスから少ないインターフェイスに移動させ、bondのリバランス期間が過ぎると、OVSはトラフィックを測定しソースMACハッシュに基づいてトラフィックを分散します。

ソースMACからのトラフィックはBondの利用率を均等にする為、トラフィックの低いインターフェイスへ移動するかもしれません。完全にバランスが取れた状態が常に可能という事ではありません。

ここの仮想マシンのNICはbondの中の一つのインターフェイスを利用します。複数の仮想マシンNICを持つトラフィックはハッシュアルゴリズムに基づきインターフェイス間で分散されます。

結果的にはAHVが10Gbpsのインターフェイスを2つ持っている場合は、AHVは20Gbpsのスループットを利用できるが、VMは10Gbpsのスループットの利用となります。


デフォルトのリバランス間隔は10秒ですが、ソースMACアドレスハッシュの過度は移動を避けるために60秒にする事を推奨しています。

(現在のKBでは60->30となっています。)

私たちはこの構成を2つの上位スイッチとAcropolis Hypervisorで確認しています。

追加のスイッチの構成無しに、スイッチとの相互接続さえ出来ていれば利用可能です。


balance-slbは全てのCluser内の全てのAHVノードで次の通り実行する事で設定可能です。


nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 bond_mode=balance-slb"

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 other_config:bond-rebalance-interval=60000"

ー>現在はbond-revalance-interval=30000

設定の確認は次のコマンドで可能です。
nutanix@CVM$ ssh root@192.168.5.1 "ovs-appctl bond/show bond0"
---- bond0 ----
bond_mode: balance-slb
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 59108 ms
lacp_status: off

slave eth2: enabled
may_enable: true
hash 120: 138065 kB load
hash 182: 20 kB load

slave eth3: enabled
active slave
may_enable: true
hash 27: 0 kB load
hash 31: 20 kB load
hash 104: 1802 kB load
hash 206: 20 kB load


LACP and Link Aggregation

この構成をする場合は十分に検証を行ってください。

それはLACP,balance-tcpは上位のスイッチの構成が必要であり、AHVのノードがスイッチの設定がされていないポートに接続されるとネットワーク接続が無効になるかもしれないからです。

しかし、一つのVMから複数のリンクで構成される上位スイッチに対して最大の帯域幅を利用できることになります。OVSのlink aggregationはLACPとbalance-tcpが必要です。

LACPにより複数リンクの別々の物理スイッチは一つのL2リンクとして表示されます。

トラフィックはトラフィックハッシュアルゴリズムを基にactive-activeに分散んされ、スイッチのマックアドレステーブルに関係なくlinkのメンバーで分散します。

これはuplinkが一つのL2リンクとして表示されるからです。

Link Aggregation , LACP , balance-tcpによりAHVのノードが2つの10Gbpsアダプタを搭載している場合は、一つのVMで20Gbpsの帯域を利用できます。

774iaa103d96e3c9d67d_2

LACP,balance-tcpには次のコマンドを実行します。

また上位スイッチではLACPが必要です。



nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 lacp=active"

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 bond_mode=balance-tcp"

上位とのLACPネゴシエーションに失敗した場合、デフォルトではbondを無効にしすべてのトラフィックをブロックします。

次のコマンドでLACPのネゴシエーション失敗時、Active-backupへの切り戻しを実施できるようになります。
(こちらの設定を実施時はスイッチ側の設定をこちらのKBに従って設定、確認をしましょう)

nutanix@CVM$ ssh root@192.168.5.1 "ovs-vsctl set port bond0 other_config:lacp-fallback-ab=true"

Finding the right balance

お客様の仮想化環境要件に合わせて最適なbondモードを選択しましょう。

本記事では簡単な方法から難しい方法までを載せています。

10Gbpsを2つでbondを構成すると以下の通りです。

Active-backup - AHV , VM共に一つのActive-NIC (Switch 設定不要)

balance-slb    -  AHV 20Gbps , VM 10Gbps ( Switch 設定不要)

balance-tcp    -  AHV , VM 20Gbps  ( Switch 設定必要)

記事担当者 : SI技術本部 カッシー @Networld_NTNX

Lenovoのx86サーバー ThinkSystemを選択する メリットについて学んでみよう!

$
0
0

この記事はレノボ・エンタープライズ・ソリューションズの小宮様に寄稿いただきました。

Lenovo 社が提供する x86サーバーである、ThinkSystemの価値、選択するメリットについてのご紹介となります。


レノボ・エンタープライズ・ソリューションズ小宮です。本日はLenovoのx86サーバ―であるThinkSystemをサーバープラットフォームとして選択する理由とそのメリットについてお話したいと思います。最近LenovoではNutanixおよびVMware/Microsoftなどのソリューションに対応した認定ハードウェアをリリースしています。そのため、コモディティ化されているハードウェアの中で、ThinkSystemがいかに価値があるものなのかを理解し、お客様に選定して頂くことための内容をご説明したいと思います。

 

  1. Lenovoのサーバーとは?

LenovoというとPCのメーカーというイメージがありますが、実は2014年10月にIBM社からx86サーバー事業をLenovoに売却されて、そのDNAを引き継いで事業を続けています。そのため、LenovoがIBMから事業譲渡する前にThinkServerというブランドを持っていましたが、IBMから事業譲渡された旧System xが統合されて、現在はThinkSystemという統一ブランドに一つにラインナップ化されています。

IBM社からの事業譲渡前は、IBM社のホストコンピュータで培った技術をいかにして、x86サーバーに取り込むことにより稼働率・品質向上につなげることをイノベーションとして取り込んできました。その内容について触れていきたいと思います。(ThinkSystemはLenovoの技術というより、旧IBM社の技術が詰まっているサーバーです)

Les01

構成製品のメインであるThinkSystemのサーバー、SR, ST, SD, SNシリーズのメリットについてご説明します

ThinkSystemは、タワー型、ラック型、高密度型、ブレード型からハイエンドサーバーといわれるミッションクリティカルな用途に対応できる幅広い製品を、ラインナップしています。

ThinkSystemサーバーのメリットは大きくわけて3点あります

1.管理負担の軽減

  長年の設計ノウハウによる高い信頼性と、管理プロセッサー(XCC XClarity Controller)により管理負担を軽減します

2.投資対効果の追及

  ラックの1U,2Uサーバーのポートフォリオを3倍に拡大、合わせて保守アップグレードサービスの選択肢を増やすことで必要なだけ投資することができ、投資対効果の向上を訴求することができます

3.俊敏性と時間短縮

  Light PathやPPA(Proactive Platform Alert)により、不具合による計画外停止などを少なくし、部品の共通化により保守時間短縮や保守容易性を実現します

  1. ThinkSystemの信頼性について

Les02

信頼性についてもう少し深く掘り下げてご説明したいと思います。

こちらの資料はITICにて発表されている2017年から2018年の一年間に世界中の企業の750名を超えるCIOおよびIT管理者の信頼性における調査をお客様にした結果になっています。この調査において計画外ダウンタイム(IT管理者が想定していない停止時間)が4時間以上経験しているかどうかの調査結果で、LenovoのSystem x(ThinkSystemも含む)で約1%の数値をたたき出しています。これはほぼメイン・フレームに近い稼働率の数値になっており、コモディティ化されているサーバーおいて、なぜこれだけの差がついてしまうのか?

それは、旧IBMからのテクノロジーがこの数値を支えており、これらが実現しているからこそ、ファイブナイン(99.999%)の稼働率を実現しています。同じようなスペックで他社製品と比べた時に、製品として信頼性あるものを選ぶことも重要なファクターであると思います。

  1. ThinkSystemのパフォーマンスについて

Les03

こちらは世界記録叩き出しているベンチマークの数になります。コモディティ化されているサーバーならば本来どのメーカーを選んでもパフォーマンスは変わらないはずですが、サーバーの開発段階からIntel社などの主要メーカーと緊密な協力体制のもとで製品化に取り組んでいることから、主要サーバー・ベンダーに中でもパフォーマンスが良いものを提供しています。この中には仮想化のベンチマーク、SAPなどのSAP値などの主要なアプリケーション環境でも最適パフォーマンスが出せるものになっています。現在は30もの世界記録のベンチマークがあります。

信頼性の時と同様に、パフォーマンスが良いものを購入時に選択することも一つの差別化につながります。

  1. ThinkSystemの高信頼性をもたらしているもの

Les04

高信頼性をもたらしているもの、それはこの2つのテクノロジーです。

・プロアクティブ・プラットフォーム・アラート

  • CPU・HDD・SSD・ファン・メモリー・電源ユニットなどの障害を可能な範囲で事前に検出し、通知する機能がプロアクティブ・プラットフォーム・アラートです。
    この障害検知の仕組みについてはメイン・フレームの運用から培った技術の結晶であり、稼働率向上に向けた仕組みとなっています。
  • XClarity Integratorと連携することでシステムの停止なく、仮想OSを安全に退避することができます。

・Light Path診断テクノロジー

  • サーバーの停止時間を最小化するために、ThinkSystemではLight path診断テクノロジーを使用しています。
  • LEDが点灯することでメモリーやファンなどの障害部位を容易に特定できます。障害発生時の保守作業の時間を大幅に削減することができます。

 

例えばデーターセンターでメモリ不良でサーバーが立ち上がらなくなった際に、(他のベンダーのサーバーでは)メモリモジュールが多く故障モジュールが判断つかないケースがあります。不良のメモリーモジュールを探し当てる際にメモリの差し替えを行うなどして、故障モジュールを特定するのに数時間要することがあります。

その時に、Light Path診断テクノロジーがあれば、瞬時に故障モジュールの特定も可能でサポート対応も迅速に行うことができ、顧客満足度向上につながります。

  1. 強固なセキュリティを実現するThinkSystem

Les05

2014年にIBM社からLenovoにサーバー事業の譲渡を行う際に、IBM社からLenovoに対して引き継がれた内容として、事業譲渡後も同様のセキュリティ体制(およびセキュリティレベル)を維持することになっています。そのため、製品化する際に最高のセキュリティ基準を意識して開発を行っています。

ThinkSystem サーバーのセキュリティ対応は、①ハードウェアとしての対応と、②ファームウェア開発プロセスの2つの面で対応しています

①ハードウェアとしての対応

ThinkSystemサーバーは全モデルにおいてセキュリティ対応としてTPMチップを搭載しています。

このTPMチップを使うことで、署名付きファームウェアの適用しかしないとか、ブート対象のファームウェアに改ざんがあったかを判断することができ、万一改ざんが発見された場合は、別に保存してある正しいファームウェア―で上書き(ロールバック)して、ブートすることができます。

②ファームウェア開発プロセス

また、サーバーのファームウェアの開発、リリース、適用の全体に渡り、セキュリティ管理プロセスを導入しています。

ファームウェアのリリース前のコードの厳格なテストや、デジタル署名付きでファームウェアをリリースし、ThinkSystemに搭載されたセキュリティチップにより、信頼されるファームウェアのみしかサーバーに適用できない仕組みを構築しています。

また、開発に関連する社員のセキュリティ教育にも力を入れています。

  1. 顧客満足度向上させるサポート(コールホーム機能)

Les06

サーバーのハードウェアに障害が発生した際に、IT管理者が障害に気が付いてからサポートセンター連絡するようなケースでは、障害対応を遅れてしまいます。

万が一、障害が起きた場合にユーザー様のご負担を減らすことができるのが、障害自動通報(コールホーム機能)です。

コールホームを使わないケースでは、不具合が起きたことをエンドのユーザー様が検知した後、Lenovoのサポートセンターにご連絡いただいてから修理作業に入ります。

コールホームを利用いただいている場合は、障害起きた時点で、Lenovoのサポートセンターに自動的に通報され、Lenovoサポートセンターよりよりお客様にご連絡をいたします。

さらに、自動通報時に障害が起きたサーバーのログ(構成情報、障害ログ)も自動で送付されますので、お客様側でログ取得等の手間を省くこともできます。

こちらのサポート内容はすでに一部のサーバー・ベンダーでは同様レベルの内容を提供できておりますが、コールホーム機能については旧IBM社からの機能をそのままLenovoに事業譲渡した後も引き続きご利用可能になっております。

  1. XClarityによるシステム導入後のファームウェア管理と統合管理

Les07

XClarityはレノボエンタープライズ製品を管理するための統合管理ソフトウェアです。ライフサイクルをカバーする先進機能を搭載しながら、業界標準のRedfishの採用により上位管理層との連携とオープンな管理性を提供します。

XClarityにはライフマネージメント機能の他、統合管理ツールとしての多くのメリットがあります。

画面左側は一般的に「システム管理体系」で要求される内容、画面右側はそれに対応したレノボのシステム管理製品XClarityの機能名です。

特に赤字の部分は、今回新しく名称変更、機能アップされた名称です。

例えば、従来のUEFIはXClarity Provisioning Mangaer、IMMはXClarity Controller、ToolsCenterはXClarity Essentialとなっています。

 

XClarityについては、今後のブログにて詳細のご説明致します。

 

今後ともよろしくお願い致します。

 


今回は小宮様に Lenovo ThinkSystemを採用する理由、メリットについて、ご紹介いただきました。

当社ネットワールドでも Lenovo ThinkSystem を取り扱っておりますので、ご興味のある方はぜひお問い合わせいただければと思います。

今後も、小宮様の Blog にどうぞご期待ください!

本当のMulti Cloud Manager (ver 3.1.2)

$
0
0

みなさん、こんばんは。こんにちは。鈴木です。

ひたすらIBM Cloud Private関連の内容を投稿していますが、変わらずその内容です。

今現在、IBM Think 2019が行われており、これまでいろいろを投稿させていただいているMultiCloud Managerについて新バージョン(ver 3.1.2)がリリースされました。 今回は速報でサクッとご説明したいと思います。

  • Azure,AWS,GoogleのKubernetes環境に対応

20190213_234743958_ios


画像のように、IBM MultiCloud Managerで他社製のクラウドの管理もできるようになります。 設定としては、各クラウドのKubernetes上に Klusterletという管理エージェントとなるコンテナーをデプロイする必要があります。

実際に管理している画面はこちら。

20190213_234748306_ios


実は、AWSやGKSなどは自動で判別はしてくれませんが、タグをつけることができるので、ユーザーごとに管理単位ごとにタグ付けしていただくことで、管理に柔軟性を持つことができます。


  • 検索の実行 これまでのMultiCloud Managerでは複数クラスター(これまではICPとIKSでしたが)の管理をしている場合に、どこにどのPodがあるかなどの検索の手段がありませんでした。 しかし、今回のバージョンでは Searchの機能が追加されており、Podなどの検索がサクッとできるようになっています。

20190213_235540541_ios



  • Dash boardからのドリルダウン 地味ですが、管理者には素敵な機能です。
    これまでは、Dash boardの一覧で問題があったホストなどがあっても、Dash board上からはドリルダウンできない場所もありました。 今回のバージョンでは、Dashboardの一覧から問題のあるHostなどに対して、すぐにドリルダウンできるようにインターフェースが改良されています。


  • インストールに関して IBM MultiCloud Manager 3.1.2が最新になりますが、これを使う場合にはICP3.1.2が必要になります。
    ICP3.1.2のインストールもMultiCloud Managerのインストールも試していませんが、MultiCloud ManagerのKulusterletについては 提供時のファイル名が大きく変わっていましたので、手順の再確認をする予定です。
    (現地でSEに確認する限り、方法は変わっていないようですが・・・)


インストールについては改めて弊社で検証後、記事として投稿させていただきますのでお待ちください。


IBM Knowledge Centerではすでにドキュメントが公開されています。

ICP 3.1.2の新機能
https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/getting_started/whats_new.html

MCM3.1.2の新機能
https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/mcm/getting_started/whats_new_mcm.html



以上となります。 さらっとですが、これまで どこまで対応するの?MultiCloud Managerという部分がやっと見えてきました。

トライアル等、デモ等ご要望がございましたら是非ご連絡ください。

すずきけ

Viewing all 459 articles
Browse latest View live