主題はシナリオを要約します。答えはダウンタイムがないということだと思いますが、システムは再構築中に単に遅くなる可能性があります。どちらでも構いません。しかし、ダウンタイムがある場合、どのくらいの期間ですか?メンテナンスウィンドウを短くするための小さなブリップは許容されます。再構築の日数は、処理方法を評価するための新しい計画が必要になります。
詳細:クライアントには、12ベイのラックマウントユニットであるSynology RS2414RP +(DSM 5を実行)に接続するiSCSI接続があります。最初にセットアップされてから、すべてのベイに3TBドライブが搭載されています。また、1つの大きなiSCSIボリューム専用のデバイスであるため、最大量のスペースを使用するように設定されています。そのスペースのサイズが約1GBであるにもかかわらず、これは何ヶ月も機能しています。
現在、システムは「読み取り専用」モードになっていることがあります。これは、iSCSIボリュームのシンプロビジョニングがボリューム自体の外側の制限に達したことが原因であると考えられます。 SSHを使用してPostgreSQLデータベースの古い/サイドバイサイドバックアップを投入することにより、ボリュームを「復活」させることができました。これにより、iSCSIパーティションを保持する基盤となるボリュームの約36MBのスペースが解放されました。これは、iSCSIボリュームを再度マウントするのに十分な余裕でした。しかし、明らかに、起こるのを待っている問題です。
したがって、このSynologyユニットのボリュームは2ディスクフォールトトレランスのSynologyハイブリッドRAIDセットアップとしてフォーマットされているため、3TBドライブの1つを4TBドライブに交換してボリュームを拡張することにしました。ドライブが挿入され、フォーマットされ、糖蜜のパリティチェックステージとして低速で実行されています。
ただし、パリティチェックが完了したら、ボリュームを拡張するためにログインする必要があります。この最終段階で、サービス停止の観点から何が起こりますか? Synology DSMがLVM(Logical Volume Manager)などの標準的なオープンソースツールに基づいているので私がオンラインで読んだものから、 ボリュームは停止することなく拡張されます 。しかし、27TB以上のストレージについて話しているので、私の仮定が正しいことを2倍または3倍に確認したいと思います。
これは基本的に:パリティチェックが行われ、ボリュームを拡張すると、すべてのサービスが引き続き稼働し、拡張が発生しますバックグラウンドプロセスとして、ダウンタイムをゼロにしますか?
ダウンタイムは発生しません。これは、常にアップアベイラビリティが重要であるエンタープライズで現在行われている標準的なことです。
LVMはこの拡張をバックグラウンドで実行しますが、ほとんど瞬時に実行され、サービスには影響しません。私はこれを週に1〜2回自分の不動産で実行し、まだ問題は発生していません。