サーバルーム内に設置しているデータサーバに障害があり、増設用に購入。DELL のラックサーバを増設するにはストレージを固定するトレイ（マウンタ/ドライブベイホルダーキャディ）が必要になるので、闇市以外で購入するにはメーカーに発注するしかありません。そうすると10万円ぐらいの価格がするんですよね……。通常の PC を扱うショップには置いていない SAS ドライブになるので、まぁそういうビジネスなんですが。

SAS インターフェース（Serial Attached SCSI）を採用しており、12 Gbpsという高速なデータ転送能力を持ち、エンタープライズ用途に応える安定性を持っています。一般的な HDD は 6Gbps になるので約2倍の速度になりますね。

巷では「海門」とか「WD」とかそれっぽい言葉で議論されることが多いのですが、プロ業務では

「そんなことよりスピード」と片付けられて耐久性とかあまり語られることはありません。

この理由なのですが、復旧するまでのスピードが求められるので、そもそも転送速度が重視されるかららしいです。物理では必ず壊れることが決まっている未来なので、そこからどうリカバリーするかがプロの業務になっているらしい──だそうです。客観的に言ってるのは、僕がネットワーク業務のプロじゃないからです。

8TB, 12TB, 16TB といった大容量を SSD で賄うのは依然として非常に高価です。

SATA HDD でも大容量は可能なのですが、今度は信頼性や耐障害性で SAS に劣る。

つまり「大容量＋信頼性」のバランスを取りたいユーザーには SAS が最適になります。

SAS はプロ仕様の接続設計で、冗長性や信号品質への配慮が組み込まれており、データセンターやサーバー用途に最適です。

設計思想の違いで言えば、SAS は、設計者が「高性能・高信頼・安全性」を求めるユースケースに合わせて、堅牢な通信フレーム、冗長性の確保、自己診断／管理機構の強化など、より複雑な設計を前提としています。

それとは別に SATA は、コストと容量効率を重視しつつ、個人向けや単純なサーバー用途に適したシンプルな構造です。

SAS では Advanced Format の512e形式を採用しており、オフセットされたセクタにより物理フォーマットと論理フォーマットの整合性を保ちながら、効率よくデータを扱う設計になっています（※ただし、VMware 環境では一部制限がある。512e は Windows Server 2008 R2 以降や一部 Linux でのみ正式サポートされています）。これは、記録効率やエラー訂正能力を高めるための技術です。

例えば、大きなファイルを読み書きする場合、4096バイト単位で処理する方がディスクアクセス回数が減るため、速度が向上することがあります。各セクタにはヘッダーやエラー訂正コード（ECC）が含まれ、セクタが大きくなると、ヘッダーの数が減るため、オーバーヘッドが少なくなり、実質的なデータ転送効率が向上します。

ただし、小さなファイル（数百バイトなど）を頻繁に書き込む場合、4KBセクタだと無駄な書き込みが発生することがあります（「ライト・アンプリフィケーション」）。動画編集や大容量ファイルの保存など、連続データの読み書きが多い用途ではAFTの恩恵が大きいです。

この HDD は、機能美を兼ね備えたエンタープライズデザインの体現です。高速かつ信頼性の高い SAS インターフェース、効率的な 512e セクター、ホットプラグ対応による運用性の高さ、純正品としての互換性保証などが相まって、「設計の完成度」として非常に高い評価ができます。

HDD が1つのはずなのに、わりと大きめの梱包で送られてきました。

緩衝材分厚いな。でも HDD は固定されておらず、この中で動き回っている状態です。

緩衝材があれば固定しなくても良い物なんですね。

このラックサーバは4つのスロットがあるのですが、1つは空いている……というか、勝手に増設したHDDが入っていたので、それを抜きました。

ホットプラグに対応しているので、そのまま差し込むだけです。

 システム稼働中でも容易にディスク交換が可能です。これにより冗長性の高い運用が可能になり、ダウンタイムを極力抑える設計としての意図が明確になっています。

 今回は。壊れた HDD の交換ではなく、増設を行いました。

容量いっぱいまで使い切ってしまい、空き容量が無いため立ち上がらなくなったサーバを削除し、HDDを発注、届くまでの間に復旧作業をし、そこに領域を追加させるという方法を取りました。この手順が後で失敗となるのですが……。

そもそも、Cドライブとデータドライブを分けていれば起動できる空き容量を確保できね？ と思うのですが、その解答が仮想サーバの仮想ディスクの方がいっぱいになり、今回の仮想サーバが立ち上がらなくなりました。

サーバーは24コアCPU×1、OSライセンスは16×3で48コアライセンス分となるので、サーバー上で4ゲスト立てる構成となります。

その4つの仮想サーバのうちひとつが容量を圧迫し、すべて使い切ってしまったというのが原因です。

この仮想サーバは大容量のデータを読み書きするもののため、拡張性を持たせるために容量可変ディスクで構成していました。

容量可変ディスクでは仮想マシンで使うデータ量に合わせて、仮想ハードディスクのサイズは後から自動で広がっていきます。最初に「これくらい使うかも」と最大容量を設定しますが、実際にはその分すべてをすぐに確保するわけではありません。必要になった分だけ少しずつディスク領域が割り当てられるので、物理的なハードディスクの空き容量を無駄なく使えます。ちなみに、仮想マシンを作るときは、この可変サイズのディスクが標準で選ばれるようになっています。

この仕組みで、基盤から割り当てられた領域がいっぱいになり、サーバが立ち上がらなくなったというわけです。

 この時、データは 14.5TB あり、サイズ的にコピーさせて避難させる領域が無いため、復旧させるためにまずは一端データを削除させて空き容量を確保するしかありませんでした。

データだけレプリケーション同期させていたバックアップサーバ（低スペック）を稼働させ、復旧作業中に業務が止まらないようにして、その間に障害の起きたサーバを一度削除した後に最初から構築し直し、直前までバックアップしていたデータを元に戻すという方法を取りました。

これは DFSレプリケーションを信用していないことからで、データの取りこぼしが無いように完全バックアップの方を復旧させ本データとすることにしました。