以降 JSUC と略記、short URL: https://ibm.co/3fV3qzE）とは、お客様やビジネス・パートナー様とIBM専門家が連携し、ストレージについて学び、アドバイスやベストプラクティスを仲間と共有し、製品やコミュニティー・イベントに関する情報を得るためのものです。どなたでも自由にご参加いただけますので是非ご参加ください。JSUCへの登録ガイドはこちらです。
注： 当該グループ上でご紹介する情報は、日本アイ・ビー・エム（株）が必ずしも正式なレビューを行ったものではありません。
Storage Scale System（以下SSS, 旧ESS:Elastic Storage System）の耐障害性についての紹介です。
SSSのディスクへのI/Oは、拡張筐体内のディスクをRecovery Groupとして2分割し、２つのIOサーバがそれぞれ別のRecovery Groupに対してPrimaryパスとしてI/Oを処理します。
Recovery Group内のディスクは、Declustered Arrayと呼ばれるアレイを構成するpdiskのグループとして構成されます。 SSSではStorage Scale のSoftware RAIDを採用しており、これらのpdiskに対してvdisk（Storage ScaleでいうNSD）として構成する際のRAID codeは以下が選択可能です。
・4-way （ユーザ領域は物理サイズの1/4）
・3-way （ユーザ領域は物理サイズの1/3）
・8+2P （ユーザ領域は物理サイズの80%）
・8+3P （ユーザ領域は物理サイズの73%）
またStorage ScaleのSoftware RAIDの構成データは、筐体障害でも冗長構成が保てるように自動で配置されます。そのため、8+2Pであれば５筐体構成で、8+3Pであれば４筐体構成で、筐体障害に耐えられる構成となります。
SSSでvdiskを構成する場合のデフォルトは8+2Pで作成されます。一般的には2台のディスクの同時故障でも稼働可能な8+2Pでも耐障害性は十分と思われますが、拡張筐体数の検討に当たっては容量の観点だけではなく、耐障害性も考慮して検討することが必要です。
またSSSはRecovery Group単位でI/Oサーバを切り替えてエラーリカバリーを実施します。 そのため特定のvdiskがRAIDの冗長構成を失ってI/Oがエラーとなった場合、同一のRecovery Group内の他のvdiskもその影響を受けてしまいます。つまり、以下のように8+2PのRAID CodeのvdiskでI/Oが継続できないような筐体障害が発生した場合、3-wayのvdiskがRAID上では冗長構成を保っていたとしても、8+2PのI/O障害のリカバリーで、3-wayのvdiskへのIOも影響を受けてしまいます。Recovery Group内では耐障害性の低いRAID Codeに引きずられてリカバリー処理が行われるため、同一Recovery GroupではRAID Codeを統一することがおすすめです。
Copy