今年もゆるめに更新していきます。
今回もまた運用者目線シリーズです。
Nutanixは運用が非常に楽になるというメリットがありますが、
そのノウハウやTipsが日本国内では
まだあまり多くないのが実情です。
少しでもシェアすることで、
Nutanixを上手く扱える人が増えれば、
そしてファンが増えればよいと思い、
投稿しています。
今回はAOSのバージョン選びについて取り上げます。
１．AOSのバージョンの読み方と投入サイクル
本稿執筆時点では、最新が5.10.0.2です。
ざっくり言うと、「5」のところがメジャーバージョン、
「10」のところがマイナーバージョン、
それ以降が細かな修正パッチを含む
VMで言えばUPDATEのようなイメージですね。
AOSはクラウドライクな機能追加を目指しており、
現在は四半期ごとに新しいバージョンが投入されるようになりました。
基本的にはカレンダーイヤーの四半期ですので、
1～3月、4～6月、7～9月、10～12月に
1度ずつということになります。
直近の10～12月のリリースとして、
「5.10」がリリースされています。
この四半期リリースごとに、
メジャーかマイナーのいずれかの形で、
バージョンアップ版が投入されていきます。
次は1-3月期になりますので、
また直近新しい機能が投入されてくることになりますね。
２．運用者が押さえておきたいSTSとLTS
ソフトウェアで必ずつきものであり、
運用者が必ず把握しておかないといけないことは、
サポートサイクルです。
Nutanixでは、２種類のサポート期間が設定されています。
・STS(Short Term Support)
・LTS(Long Term Support)
STSの方は、
フルサポート：3か月
追加サポート：3か月
→計6か月
のサポート期間となります。
一方のLTSは、
フルサポート：15か月
追加サポート： 6か月
→計21か月
です。
最長で21か月のサポートになります。
このSTSかLTSかは、
メジャーバージョンに紐づいているわけではなく、
マイナーバージョンも含めたバージョンに付与されます。
比較的直近のバージョンで見てみると、
5.5→LTS
5.6→STS
5.8→STS
5.9→STS
5.10→LTS
ということになります。
※5.7はNutanix社内の都合でリリースバージョンとして飛ばされています。
つまり、今回採用しようとしているバージョンが、
LTSなのかSTSなのかは都度確認するようにしましょう。
３．初期導入時にハマりがちなバージョン選択の罠
Nutanixの導入経験が浅いSIerや
利用者がやりがちなこととして、
バージョン番号と投入されている機能だけ見て、
投入するバージョンを選ぶ、ということがあります。
例えば
「ベンダーが売りにしている最新機能を使いたいが、
ソフトウェアは最新バージョンだと怖いので、
ひとつ前のマイナーバージョンを選ぼう、
これなら目的の機能も搭載されている」
というような選び方です。
安易だ・・・と思われるかもしれませんが、
現場あるあるだったりします。
この選び方ですと、STSにあたる可能性もあり、
購入→SIerによる構築をやっている間に、
・次のバージョンが出ました
・構築作業にはバージョンアップ作業は見込んでません
・顧客側もやったことがありません
・そのバージョンを提案してきたのはSIerなので、
やるのが当たり前だ
というような、不毛な争いになりかねません。
採用時にはLTSとSTSのどちらのバージョンかを確認し、
導入計画やその後の運用計画まで含めて、
バージョンの選択を行うようにしましょう。
４．メンテナンスについて考える
前項までに、LTSやSTSのサポート期間について触れました。
誤解を恐れずに言えば、どんな環境であっても、
1年～1年半に1度は必ずバージョンアップを行う必要があります。
こう聞くと、Nutanixの運用は負荷が上がると考えてしまいがちです。
しかしながら、Nutanixでは、パッチのダウンロードや、
適用作業の自動化機能が搭載されており、
バージョンアップ作業を楽にする工夫がされています。
更に、ソフトウェアのバージョンアップと言えば
失敗のリスクが伴いますが、
Nutanixではヘルスチェックツールが標準で実装されており、
事前にこれを活用することで、
失敗するリスク要因を排除できます。
運用者に非常にやさしい作りです。
適用作業についての詳しくはこちらの記事もご覧ください。
加えて、短期間でのバージョンアップの対応は、
「サイバーセキュリティ」に対する対策としても効果を発揮します。
多くのシステムは何らかの形で外部と、
インターネットとつながっている時代です。
ソフトウェア脆弱性の放置をしてしまうと、
攻撃対策にかけた何億円ものお金を水の泡にしてしまいます。
AOSのバージョンアップ時には、
セキュリティ対策に関する修正も含まれています。
計画的なバージョンアップを実施することで、
これらの対応も合わせて行えるメリットがあります。
ですので、決してバージョンアップをネガティブにとらえず、
やらなけばならないことを実行する期限を
むしろ設定してもらっているような感じです。
ESXiのバージョンアップが導入以来されておらず、
脆弱性を放置しているケースは少なくないと思います。
特に導入時にUpdate Managerを入れていないケースは多いので、
バージョンアップは少々面倒な作業となります。
そこにきて、先日あったような、
インターネットにESXiが公開されてしまっていたようなことがあると
色々終わり・・・ですね。
サイバー攻撃を受けて情報漏洩した場合、
どうしても責任は運用をしている部隊に向けられがちです。
バージョンアップをしていなかったことが、
運用者の怠慢だと言われることは避けなければなりません。
AOSやAHVに変更することで、
バージョンアップ作業自体の負担を軽減しつつ
定期的なセキュリティ対応をさぼらない環境を作り、
自分たちの身を守るという考え方もぜひ持ってみてください。
今回の投稿は、以上です。
