Azure Native Qumulo が EU、英国、カナダで利用可能になりました – 詳しくはこちら

「すべてのテクノロジー企業は、アップデートを展開する方法についてのレッスンが必要です。Qumulo のように実行してください…」。 — 匿名の顧客

作成者:

新しい月例シリーズを始めるにあたり、すべてのお客様が経験するもの、つまりアップグレードについてお話しましょう。 古典的な「再起動が必要」であろうと、「すぐに起こるので見逃した」であろうと、アップグレードは死と税金と同じように確実に起こります。  

この分野では Qumulo も例外ではなく、かなり定期的なペースでアップグレードがリリースされています。 Qumulo がリリース 3.3.2 で OS をコンテナとして実装したとき、プラットフォームとインスタント アップグレードの概念も導入しました。 最も基本的なレベルでは、同じことを、ほとんど同じ方法で達成します。 どちらもイメージをすべてのノードにコピーします。 どちらも、アップグレードが成功することを確認するために、一連の事前テスト (口語的には飛行前チェックリストと呼ばれます) を実行します。 最後に、どちらも何らかのシステム再起動を行います。インスタントの場合はコンテナー、プラットフォームまたはローリング リブートの場合はノードのいずれかです。

サポートでよく寄せられる質問の XNUMX つは、「アップグレード パスは何ですか?」または「バージョン X からバージョン Y に移行するにはどうすればよいですか?」です。

リリース命名スキームの内訳から始めましょう。   

XYZa

場所 

X は会計年度です

Y は 0 から始まる会計四半期です。

Z はその四半期のリリースです

いくつかの追加機能が組み込まれている場合に必要に応じて存在します (例: サードパーティのサポート性、ファームウェア、および時折のバグ修正)

たとえば、5.3.4 は次のようになります。

会計年度 5、第 4 四半期、四半期内 XNUMX 回目のリリース。

何でこれが大切ですか? Qumulo には、いわゆる「四半期リリース」があり、0 桁目が 0 (四半期ごとの最初のリリース) で示されます。 これらについては特に空想的なものはなく、暦年の中でたまたまそこに到達するだけです。 ただし、これらは次の四半期へのステップ ポイントとして使用されるため、Qumulo の顧客は、.XNUMX 四半期リリースごとにアップグレードする必要があります。

最近、2 年間システムに触っていなかったお客様と話をしました。 壊れていない場合は、修理しないでください (これについては後で詳しく説明します)。 四半期ごとの .0 リリースごとにアップグレードする必要があったため、ご想像のとおり、アップグレード パスはかなり長くなりました。

3.2.0 -> 3.3.0 -> 4.0.0.2 -> 4.1.0.1 -> 4.2.0 -> 4.3.0 -> 5.0.0.1 -> 5.1.0.1 -> 5.2.0.2 -> 5.3.0 -> 6.0.0.2 

アップグレードに関して次によく聞かれる質問は、「どれくらい時間がかかりますか?」です。 インスタント アップグレードは通常 10 秒以内に行われるため、アプリケーションが気にすることはほとんどありません。 プラットフォームのアップグレードには、システムの起動にかかる時間と同じくらいの時間がかかります。通常は 5 ~ 10 分の範囲です。 上記のアップグレード パスを使用し、インスタント (I) またはプラットフォーム (P) の場合に追加すると、次のようになります。 

3.2.0 (P) -> 3.3.0 (I) -> 4.0.0.2 (I) -> 4.1.0.1 (I) -> 4.2.0 (I) -> 4.3.0 (P) -> 5.0.0.1。 5.1.0.1 (I) -> 5.2.0.2 (I) -> 5.3.0 (P) -> 6.0.0.2 (I) -> XNUMX (P) 

上記を考慮すると、プラットフォームが 8 分であると仮定すると、そのうち 4 分と 7 つのインスタントが表示されることになります。 合計 35 分間のギブ・オア・テイクと言えます。 XNUMX 時間のスケジュールを立てて、十分な仮眠を取りましょう。

プラットフォームになるか即時アップグレードされるかを確認するための優れたドキュメントは、次の場所にあります。 docs.qumulo.com ページ こちらをご覧ください。..  

これを見て、6.0.0.2 が「即時、四半期ごと」と明記されているのに、なぜプラットフォーム アップグレードとラベル付けされたのか疑問に思っているかもしれません。 ここで、次のアップグレードに関するトリビアが登場します。   

このグラフを下にスクロールすると、5.3.1 でプラットフォームのアップグレードが行われたことがわかります。 このバージョンは四半期ごとの 6.0.0.2 の一部としてリリースされるため、そのプラットフォームのアップグレードは四半期ごとのリリースに組み込まれます。 微妙な違いですが、それを求めていない場合は不意を突かれる可能性があります。  

これについて蝶結びをする前に、私がほのめかした最後の 2 つのことが重要になります。 XNUMX つ目はハードウェア関連です。 ムーアの法則とは直接関係ありませんが(ゴードン・ムーアよ、安らかに眠れ)、ハードウェアの進歩はサラブレッドのような速度で起こります。 そのため、今年発売されるハードドライブのような無害なものは、XNUMX 年前に作成されたソフトウェアに対してテストされていません。 Qumulo では、コード内の内部ハードウェア互換性リストを管理しています。 これらのコンポーネントは、高水準を保証するために厳格にテストされています。 そのため、古いリリースを実行していて交換が必要な場合、新しい部分が古いソフトウェアに対して認定されていない可能性があります。 このような状況は時々発生し、通常はソフトウェアをより新しいリリースにアップグレードすることを検討します。   

もう XNUMX つの注意すべき項目はレプリケーションです。 Qumulo の最新バージョンでは、四半期ごとのリリースが XNUMX つ以内であることが必要です (これは、上記の命名スキームの XNUMX 番目の数字です)。 アップグレードを計画するときは、この点に留意してください。たとえば、ソースの数週間前にディザスタ リカバリ サイトをアップグレードする予定がある場合は特に注意してください。 来月、レプリケーションとそれに関連するベスト プラクティスについて詳しく説明しますが、現時点では、ご質問、コメント、または懸念事項がある場合は、専用の Slack チャネルで Qumulo サポートにお気軽にお問い合わせください。

来月まで…

関連記事

上へスクロール