VMware Cloud on AWS について ⑦HCXつづき
みなさまこんにちは。ド文系です。
今回は前回の続き、HCXで移行したいなー、
と思ったときに考えないといけないことについてお話します。
前回の記事にもチラッと載せていましたが、
まずHCX自体が使える条件として、
・移行対象の仮想マシンのディスク容量が 2 TB未満
という条件があります。
なので、ファイルサーバを移行させるような場合は、ちょっと工夫が必要になるかもしれません。
ただ、AWSと25bpsの線で結ばれているので、
ONTAPとか、AWSのマーケットプレイスにあるようなサードパーティ製品をお使いの方はVMCへ移行することにこだわらず、CVO on AWS を使うなどの手段も選べます。
この柔軟性も、VMware Cloud on AWS のいいところですね。
ちょっと脱線しましたが、
あと2点、考慮が必要な事があります。
・オンプレ側のリソース
・（L2延伸をするなら）vDS と Edge の有無
の2つなのですが、
まずリソース、
HCXを使えるようにするためには、オンプレ側にいくつか（マックス4台）コンポーネントを立てないといけないのですが、
これが地味にリソースを持っていきます。
なので、この子達を立てる余裕がオンプレ側には必要になってきます。
固定IPも必要ですし、カツカツで運用している環境だと、苦しい場合もあるかもです。
vDSやEdgeについては、無停止での移行（ライブマイグレーション）が必須でなければなくても大丈夫ですが、
ライブマイグレーションが必須条件の場合はL2延伸をするのに絶対に必要になるので、
ない場合は要件を緩めるか、スタンドアロンエッジをたてるか、作戦を考える事になります。
短いですが、今回はこの辺で！
そして私事ですが、今月末サンフランシスコで開催される、VMWorld2019に参加させていただけることになりました！！
会社の貴重なひと枠をこのド文系に使わせてしまった申し訳なさ半分、楽しみ半分な感じですが、全力で満喫してきます！
VMware Cloud on AWS について ⑥仮想マシンの移行
みなさまこんばんは。ド文系です。
突然ですがわたし、日記とかって3日も続いた事ないんですよね。
「3日坊主」ってなんならすごくありませんか？え、3日も毎日書いたの？っていう。
メールとかLINEとかも全然マメに返せませんし、
つまり何が言いたいかって、
ご無沙汰してしまいすみませんでした。。。。。
せめて毎月1つは記事を書こうと…思っていたのですが…無念orz
気を取り直して、今日はVMware Cloud on AWS における仮想マシンの移行についてです。
VMware Cloud on AWS を使い始めるにあたり、
現在の環境（オンプレミス）から、多少なりと仮想マシンを移行してくることがほとんどだと思います。
VDI環境としてだけ使うなら、マスターイメージさえ持ってくれば良いので、
ふつうにOVAをエクスポートして、それをVMC上で展開すれば移行完了です。
でも、24時間365日バリバリ動いているサーバを、
OVA取得のために停めるというのは、出来れば避けたいですよね。
そんなときに使えるのが、VMC最大の売りと言っても過言ではない、HCX（Hybrid Cloud Extention）です。
そもそも、オンプレミス⇔VMware Cloud on AWS 間で考えられる移行方式は、
大きくこの4つです。
この中で唯一、完全無停止で移行できる可能性があるのが、HCXです。
HCXの中にもさらにいくつかの移行方式があって、
それぞれ良いところと惜しいところがあり、使える条件も違います。
ざっくりご紹介するとこんな感じです。
上記のほかにも必要なもの、考えないといけない事があるのですが、それはまた別の機会に。
VMware Cloud on AWS について ⑤基本仕様
こんばんは。ド文系です。
みなさま先日の超大型連休はいかがお過ごしでしたでしょうか（日本語合ってますか？）
おかげさまでわたしは夢の10連休だったわけですが、
見事にどこにも行かず、ずーーっと家で Youtube を見ていました。
卵焼きにバターを丸ごと一本突っこんでみたりとか
バターを丸ごとから揚げにしてみたりとか
そんな動画をひたすら見ながら、副業にYoutuberもありかなーなんて血迷ってみたのですが、
Youtubeって、10万回再生されてやっと1万円の収入なんだそうですね。
覆面のアラサーがバターを丸ごと揚げる動画が10万回も再生されるとは思えないのでやめました。
話が脱線しましたが、本日は、社会人としてのリハビリもかねて、
VMware Cloud on AWS の基本的な製品仕様についてご紹介します。
基本的な仕様は、以下のような感じです。
上記は、必ずオンプレと両方使ってハイブリッド環境にしてねということではありません。
もちろん、オンプレミス環境を持たずに、VMware Cloud on AWS 単体で使う事もできます。
ただ、その場合も、仮想マシンの移行などに際し、
一旦はオンプレミスと接続することがほとんどかと思いますので、一度は↑のような環境になるかと思います。
VMware Cloud on AWS の便利なところはいろいろありますが、
エンジニアもどきのド文系としてはやっぱり、
オンプレミスとの間で、大きなダウンタイムを発生させずに仮想マシンを行ったりきたりさせられる、
つまりは「取り返しがつく」ところが嬉しいですよね。
AWSとかに移行させるには、仮想マシンをAWS仕様にコンバートする必要があるので、
戻す時にも当然またそれが発生します。
それにあたってそのマシンは一旦電源OFFになるので、それが大事なサーバだった場合、目も当てられません。
でもVMware Cloud on AWS なら、そういったコンバートが不要なので、
移行させちゃったあとで「あっやっぱり違った！これはオンプレで動かさないといけないやつだった！」っていうときも、すんなり戻せます。なんという安心感。
ただ、
オンプレから移行してくるときに仮想マシンハードウェアバージョンを上げてしまうと、場合によってはオンプレ側に戻せなくなっちゃうので、そこだけは要注意です。
なんとーーーーー！！！！！（あっ、チャットサポートの件です）
ご無沙汰しております。ド文系です。
なんと…
なんと……
VMware Cloud on AWS のチャットサポートがついに
日本語に対応しました！！！！！ﾄﾞﾝﾄﾞﾝﾊﾟﾌﾊﾟﾌー
これでもう、Google翻訳のタブを何十枚も開いてコピペする生活ともおさらばです。
チャットでもBest Regard って使うの？とか、
ミスターなのかミスなのか分からない人はなんて呼べば？！とか、
全然本題と関係ないことを調べてアワアワした日が懐かしくもあります。
ちなみにチャットで Best Regard は使いませんし、
ミスターだろうとミスだろうと呼び捨てにすればOKでした。
このアップデートに伴い、
何でも24時間リアルタイムでサポートする仕組みも変更になったようです。
今後のサポートは以下の形になります。
・日本語でのサポートは、平日 9時ー18時
・Sev1 にあたる緊急事態に限り、平日と祝日は英語のサポートを24時間利用可能。
・土日はチャットサポート利用不可。平日まで待つか、SRで問い合わせる必要あり
確かに各国言語で24時間体制のサポートなんてしたら、人件費がとんでもないことになりますもんね。。。
ただ、18時までというのが思っているより早くて、うっかりすると過ぎているので要注意です。
VMware Cloud on AWS について ④チャットサポート
おひさしぶりです。ド文系です。
今回は文系歓喜の機能、チャットサポートについてご紹介します。
もうね、ほんとに、超ありがたいです。
わたしはSIer所属のエンジニアなので、
お客様からはプロフェッショナルとかエキスパートとか、そういう風に見られる立場ではあるのですが、
言っても文系のぺーぺー。分からない事の方が多いですし、
なにを作っていても、絶対1回はつまづくわけです。
オンプレとVPNが繋がらないぞ…とか
よく分からないエラーメッセージが消えないんだけど大丈夫なのコレ？とか
OVAが展開できないんですけどー！とか。
そんなときにリアルタイムで助けてくれるのが、チャットサポートです。
控えめすぎて分かりにくいですが、
こことか
こことか
から、トークを開始できます。
海外のメーカーの公式サイト等には大体あるので、
「なんだそんなの珍しくないじゃん」という方もいらっしゃるかと思いますが、
それ系ってほとんどがBOTじゃないでしょうか。
VMware Cloud on AWS のチャットサポートのすごいところは、
BOTではなく、ちゃんと中の人がいるところです。
基本は文字ベースで一問一答な感じですが、問題がなかなか解決しない時などは、
Zoom等でこちらの環境にログインして、中身を見てくれたりもします。
なんたる手厚さ。
My VMwareからSRを切るのは結構面倒ですし、
ちょっと教えて欲しい事がある程度で利用するのは憚られますが、
チャットなら何でも気軽に聞けるので、本当に便利です。
私については使い倒しすぎて、多分ですけど、中の方々に名前を覚えられていると思います。
唯一の欠点は、
使える言語が英語のみというところですが、
Google翻訳を別ウィンドウで開いて、コピペコピペコピペあとは根性
で何とかなりますので、みなさんも是非使い倒してください。
VMware Cloud on AWS について ③vCenterが使えるようになるまで
みなさまこんばんは。ド文系です。
今回は vCenter を触れるようにするためのステップをご紹介します。
前回作ったかわいいSDDC、
「よっしゃあさっそくログインしてやるぜ！！！」と勇んで接続しようとすると…
↓
↓
↓
こうなります。
というのも、VMware Cloud on AWS 環境の vCenter には、デフォルトで
「あらゆる場所からの接続を拒否する」ファイアウォールルールが入っているんですね。
なので、vCenterへアクセスする前に、ファイアウォール設定を追加してあげる必要があります。
どこから設定するかというと、
トップ画面から
↓
↓
ここで、「新しいルールの追加」から、vCenterへの接続を許可するルールを設定します。
特定のIPを指定しても良いですし、
勉強・検証用のおもちゃ環境であれば、Anyで解放するのもありです。
この設定が完了すると、晴れてvCenterへアクセスする事ができるようになります。
ここまでくれば、あとはオンプレとほぼ同じです。
マネージドサービスのため、グレーアウトしていて編集できない設定が結構あるのですが
チャットサポートでお願いをすれば、変えてもらえることもあります。
次回はこの「チャットサポート」についてご紹介します。
VMware Cloud on AWS について ②土台のデプロイ
ご無沙汰しております。ド文系です。
前回の記事から時間が空いてしまいましたが、
本記事ではVMware Cloud on AWS における、土台（vSphere環境基盤）の構築手順をご紹介します。
①まずはVMware Cloud Service のアカウントを作成
https://vmc.vmware.com にアクセス
↓
↓
入力したメールアドレスにメールが届く
②メール記載のリンクから、コンソールにログイン
③Create SDDC より作成開始
④ウィザードに従ってポチポチ （5STEP）
あとは1時間半ほど待つだけです。
⑤SDDC完成
いかがでしたでしょうか。
VMware Cloud on AWS では、オンプレミスでは考えられないスピードでvSphere環境の構築が完了します。
1時間半でエンタープライズ環境が出来てしまうなんてすごいですよね。
1時間半なんて、下手したらESXi の設定すら終わっていませんからね。。。。
次回は vCenter が使えるようになるまでの流れをご紹介します。
