新しい月例シリーズを始めるにあたり、すべてのお客様が経験すること、アップグレードについてお話ししましょう。 それが古典的な「要再起動」であれ、「見逃すほどの速さ」であれ、アップグレードは死と税金のように確実なものです。
この分野ではQumuloも同様で、かなり定期的なペースでアップグレードがリリースされている。 Qumuloが3.3.2のリリースでOSをコンテナとして実装したとき、プラットフォームとインスタントアップグレードのコンセプトも導入した。最も基本的なレベルでは、これらは同じことを達成し、大部分はほぼ同じ方法で行われます。どちらも全ノードにわたってイメージをコピーします。どちらもアップグレードが成功するように、一連の事前テスト（俗にプレフライト・チェックリストと呼ばれる）を実行します。インスタント・リブートの場合はコンテナ、プラットフォーム・リブートまたはローリング・リブートの場合はノードを再起動します。
サポートで最もよく聞かれる質問のひとつは、「アップグレードパスはどうすればいいのか」「バージョンXからバージョンYに移行するにはどうすればいいのか」というものだ。
まずは、リリースの命名法の内訳から見ていこう。
X.Y.Z.a
どこで
Xは会計年度
Yは0から始まる四半期
Zはその四半期のリリース
サードパーティーのサポート、ファームウェア、時折のバグフィックスなど）。
例えば、5.3.4はこうなる：
5会計年度、第3四半期、第4四半期のリリース。
なぜこれが重要なのか？ Qumuloには「四半期リリース」と呼ばれるものがあり、3桁目が0、つまり各四半期の最初のリリースとなります。 これには特に奇抜な意味はなく、たまたま暦年のどこに位置するかということです。 しかし、Qumuloでは、これらのリリースを次の四半期へのステップポイントとして使用しますので、Qumuloのお客様には、.0の四半期リリースごとにアップグレードしていただく必要があります。
最近、ある顧客と話したのだが、その顧客は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秒以内で行われ、アプリケーションはほとんど気にしないようだ。 プラットフォームのアップグレードは、システムの起動にかかる時間と同じだけかかります。 上記のアップグレードパスに、インスタント（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 (i) -> 5.1.0.1 (i) -> 5.2.0.2 (p) -> 5.3.0 (i) -> 6.0.0.2 (p)
以上を踏まえると、仮にホームに8分とすると、そのうちの4分とインスタント7分。 合計35分だ。 1時間の予定を入れて、しっかり仮眠を取ろう。
プラットフォームのアップグレードか、インスタント・アップグレードかをチェックするのに最適なドキュメントは、以下のサイトにあります。 docs.qumulo.com ページ これ..
これを見て、なぜ6.0.0.2はプラットフォームアップグレードと書かれているのだろうと思ったかもしれません。 ここで、次のアップグレードのトリビアが登場します。
このグラフを下にスクロールすると、5.3.1でプラットフォームのアップグレードが行われたことがわかります。 このバージョンは6.0.0.2の四半期リリースの一部としてリリースされるため、プラットフォームのアップグレードは四半期リリースに組み込まれます。 これは微妙なニュアンスですが、もしあなたがそれを探していなければ、油断してしまうかもしれません。
最後に2つ、この件に結論を出す前に触れておきたいことがある。 1つ目は、ハードウェア関連である。 ムーアの法則とは直接関係ないが（ゴードン・ムーア氏死去、よくやった）、ハードウェアの進歩はサラブレッドのような速さで起こる。 そのため、今年発売されるハードディスク・ドライブのような良質のものでも、2年前に作られたソフトウェアとの比較テストは行われていません。 Qumuloでは、コード内にハードウェア互換性リストを保持しています。 これらは、高水準を保証するために厳しくテストされたコンポーネントです。 そのため、古いリリースを使用していて交換が必要な場合、新しい部品が古いソフトウェアに対して検証されていない可能性があります。 私たちはこのようなケースを時折見かけますが、通常はソフトウェアをより新しいリリースにアップグレードすることを検討します。
もうひとつの注意点は、レプリケーションです。 Qumuloの最近のバージョンでは、四半期ごとに2つずつリリースする必要があります（上記の命名法の2番目の数字です）。 アップグレードを計画する際には、この点に留意してください。特に、ディザスタリカバリサイトのアップグレードをソースの数週間前に計画している場合などです。 レプリケーションとそれに関連するベストプラクティスについては来月詳しくお話ししますが、今のところ、ご質問、ご意見、ご不明な点がございましたら、ご遠慮なく専用のslackチャンネルでQumuloサポートまでご連絡ください。
来月まで...。