Pure Storage FlashArray Purity OSとバージョンアップ

Pure Storage FlashArray（FA）製品のOSであるPurityと、そのPurityのバージョンアップ方法についてご紹介します。

Purity

Pure Storage製品には、独自のOS（Operating System）である、Purityが搭載されています。FA製品、FlashBlade（FB）製品で、それぞれPurity//FAとPurity//FBに分けられます。今回はPurity//FAについて記載します。

FAには、XシリーズやCシリーズなど、複数のモデルがありますが、Purity//FAはモデルの差異に依存せず、共通のOSとして採用されています。高速なIO処理や共通のRAID設定、重複排除・圧縮機能、レプリケーション設定などは、このPurity//FAが統括してFA製品を制御することで、実施できています。

参考：Pure Storage FlashArray紹介：https://cn.teldevice.co.jp/blog/p57513/

Purityバージョンの見方と推奨バージョン

Purityは、3桁の数字で、X.Y.Zで表記されます。そのうち、X.Yをメジャーバージョン、Zをメンテナンスバージョンと表現します。メジャーバージョンのリリースでは、新機能の追加などが盛り込まれ、メンテナンスバージョンのリリースでは不具合修正が中心となります。また、メジャーバージョンではそれぞれ、SR、FR、LLRが定義されます。合わせてサポート期間（EoL：End of Life）となる年月が定義されます。

2025年6月時点で、Purity//FAの主流なバージョンは、6.5.xとなります。

当社では、LLRの中でさらに当社推奨バージョンというものを独自に定めています。これは社内検証の結果、EoLやバグの修正内容、追加機能の使用有無、フィールドでの稼働状況などを考慮した上で決定しています。

PurityバージョンがEoLになると

ご利用のPurityがEoLを迎えた場合でも、引き続き障害対応やQA等は対応可能となりますが、Pure Storageでは、その該当バージョンにて重大なバグ等が新たに発覚した場合、EoLを迎えているメジャーバージョンでは、修正版となるメンテナンスバージョンがリリースされません。また、問題発生時の原因特定に時間を要することや、特定が困難になることもあるため、EoLを迎えていないバージョンでの運用を推奨しています。

Purityのリリース状況

Purityは定期的に新しいバージョンがリリースされます。リリース状況はPure Storage社KB（Knowledge Base）から、各メジャーバージョンのリンクより、リリースノートをご確認ください。リリースノートの閲覧にはPure1アカウントが必要です。お持ちでない場合は、Pure1アカウントを作成いたしますので、保守窓口までご連絡ください。

https://support.purestorage.com/bundle/m_flasharray_release/page/FlashArray/FlashArray_Release/topics/concept/c_purityfa_release_notes.html

Purityのバージョンアップ

ここからは、Purityのバージョンアップがどのように実施されるかを説明します。

Purityは各CT（Controller：コントローラ）で動作しています。1台のFAに搭載された2つのCTのそれぞれにターゲットバージョンとなるPurityを適用し、CTを再起動することで、バージョンアップが実施されます。FAのCTは、Active/Standby構成となっており、Active側をPrimary CT、Standby側をSecondary CTと表現します。まずは、下記に、バージョンアップの作業イメージを記載します。ここでは、6.3.9から6.5.8というバージョンに、バージョンアップする際の例となります。

なお、バージョンアップ作業はすべてリモートで完結します。お客様に実施いただくことは、作業当日のRemoteAssistの有効化と無効化のみとなります。

参考：Pure Storage Pure1・PhoneHome機能・RemoteAssist機能とは：https://cn.teldevice.co.jp/blog/p57559/

CTの再起動はSecondary CT側で実施され、いずれの動作においても冗長性は確保されているため、オンラインでの作業（システム停止不要）が可能です。FAは、サーバーからのIOは両方のCTで受けます（Active/Active）が、IOの処理自体はPrimary CTにて実施する（Active/Standby）仕様となります。CT再起動時、一時的にCTとサーバーとのパスが減ってしまうため、ホストのマルチパスの挙動などにより、IO-wait（待機）が発生します。一般的に、iSCSI接続の場合は15～30秒程度、FC接続の場合は10～20秒程度のIO-waitとなりますが、データロスト等は発生せず、一時的な遅延として見えるような形で待機後にIOが処理されることで、通信は継続して行われます。

バージョンアップの仕様や注意点

・ FAに搭載されているCTは、物理的な搭載位置により、上からCT0、CT1と表現されます。上の図の例では、CT0がPrimary CTの場合の例となっておりますが、Primary/Secondaryの組み合わせは固定ではないため、CT1がPrimaryの場合もあります。その場合、SecondaryであるCT0から再起動が実行されます。

・図の2と3のCTのバージョンアップでは、まずはバージョンアップファイルの展開が行われ、その後、CTが再起動することで新バージョンが適用されます。

・現在のバージョンと、ターゲットとなるバージョンによっては、多段階のバージョンアップとなる場合もございます。その場合、段数に応じて図の2と3を繰り返す必要がありますので、再起動の回数が増えます。なお、実際にバージョンアップ作業をご検討される場合には、当社から段階をお伝えいたします。

・新バージョン適用後に元のバージョンに切り戻すことは仕様上不可となります。

・全てのコントローラ再起動前に、サーバーとのパスが、両方のCTにあるかを確認してから、CTの再起動が実施されます。

・図の5のファームウェアアップデートでは、ターゲットとなるバージョンに対しての最適化処理として、各コンポーネント（NVRAM/DFM）の新しいファームウェアがある場合に、自動的に1本ずつファームウェアアップデートが行われ、各コンポーネントの再起動が発生します。ターゲットとなるバージョンによっては、ファームウェアアップデートが行われない場合もあります。

・図の5のファームウェアアップデートでは、各コンポーネントの再起動時にLatencyが上がることがありますが、IO-wait等はなく、IOは継続されます。

・ Direct Flash Shelf（DFS）が搭載されている機器では、DFSのバージョンアップも合わせて実施されることがあります。図では4のタイミングで実施されます。DFSのCTの再起動時にはIO-waitが発生いたしますが、こちらもオンラインで作業可能となります。なお、DFSのバージョンアップ有無は事前にお伝えいたします。