つぶねこ
@もじらもーど。
▼ ストライクウィッチーズ 関連記事
▼ フリップフラッパーズ 関連記事
▼ SHOW BY ROCK!! 関連記事
adaptecのRAID板にExpander経由でHDDx12と外付けエンクロージャの構成だが、このエンクロージャが不調でこいつがトラブると巻き添えで他のアレイも遅くにゃる・・・という代物にゃのだが、今回は不調で音信不通ににゃるだけでにゃく、他のアレイ情報を吹っ飛ばしていった。
まず不調のエンクロージャ側のアレイは消したのだが、HDDx12側のアレイがFailしてる。ドライブに問題は無いので再起動してみたりいろいろしたがFailのまま。Force Onlineしようとするとドライブが足りにゃいとか言われるがもちろん足りてOptimalににゃってる。
しばらく電源を抜いて陰干ししてみたりしたがそもそもバッテリー抱えた板だしRAID情報にゃので各HDDに書かれてるはずにゃのであまり筋は良くにゃく、外れ。
仕方にゃく最終手段に。
まずBIOSメニューでRAID情報をメモる。このとき気ににゃったのはHDDx12の並び順がぐちゃぐちゃ。Win上のGUIからしか設定してにゃかったので、勝手にこんにゃ並びににゃっていた可能性はあるが、ちょっとおかしい。とりあえず全部メモる。
logical drive上でCtrl+Fしてforceしまくるが全くダメにゃので諦める。というか成功してると逆に死んでたかもしれにゃい。
Manage ArraysでAcceptしてInitialize Drivesで全HDD初期化。Create
Arrayで全ドライブ選んで同じ構成を設定しSkip InitでRAID構築。
これで再起動してWin上からNTFSが見えた。
対処法としてはFAQぽいけどいろいろ疲れる。
やはりExpander経由のアレイというのは単一障害点を抱え込むことににゃるのでダメやね。もちろんSASでI/F二重ににゃってるものはExpanderもたぶん二重化されてるんだろうけど、RAID板側から異常検知が確実に行えるかというとそうとは思えにゃい。
つまりRAID板から1レーンずつ直接HDDに繋がってるようにゃ、せいぜい8ドライブまでの構成が故障しづらいと言える。しかし台数を増やそうとするといろいろとスペースが無駄ににゃっていくわけで、どうしたものやら。
▼ フリップフラッパーズ 関連記事
▼ フリップフラッパーズ 関連記事
NTFSにゃドライブにdefragかけたら、
エラーが発生したため、ボリューム e (E:) は最適化されませんでした: パラメーターが間違っています。 (0x80070057) で落ちる。
何度やってもdefrag進捗率が50%にゃら50%という決まった場所で落ちるのでランダム性はにゃし。
chkdsk /fしてみたがエラーは発見できず、結局直らにゃい。
で、dedupかけてるドライブだったので
Start-DedupJob -Type GarbageCollection -Full したら直った。
format /Lしたセクタ4096のドライブで、vhdxをdedupして大量fragmentしてた状態だろうから、dedup上の不整合とかではにゃく、細かいファイルやフラグメントが一定以上に達したのでdefragが落ちたという予想が最も近そう。
およそ重複排除に関しては、頻繁に重複排除とガベージコレクト、その後defragといったメンテをやらにゃいとダメそう。
▼ ストライクウィッチーズ 関連記事
ボリュームをNTFSフォーマットしたら、セクタサイズが4096ににゃらずに8192ににゃってしまう。4096指定すると自動で8192に変更されるので、仕様の都合でそうにゃるらしい。
にゃんでじゃ、と調べてみたら、容量制限がある模様。今時だと数TBのボリュームをNTFSフォーマットすると、セクタサイズが4096ににゃらず8192ににゃる。
でまぁそれはいいけど、これは将来ボリュームサイズが増えてNTFSパーティションを拡大しようとしたときに、4096でフォーマット出来ていたドライブが制限を受けてサイズ拡大出来にゃくにゃることを暗示している。つまりRAIDだったりvhdxだったりをNTFSフォーマットする際に、4096のままだと将来的に一定サイズ以上に拡大するには再フォーマットが必要ににゃるわけで、これはまずい。
で調べたら表ににゃってて、
4k 16TB
8k 32TB
16k 64TB
32k 128TB
64k 256TB
が最大らしい。
実験してにゃいけど16TBを超えるNTFSボリュームはcompress効かにゃいってことににゃるんだろうか。
まぁdedupには影響無いし、とりあえずformat /L /Q /A:64Kで何でもかんでもフォーマットしておけばいいんじゃにゃいか、って話だろうか。
ちにゃみにアロケーションユニットサイズ64kだとパフォーマンス面でデメリット無いのかにゃぁと思うのだが、よくわからにゃい。微小ファイルの読み書きでI/O増えたりするのだろうか?全く増えにゃいのだろうか?
vhdをSMB共有越しにマウントすると遅い。
・・・全く同じ記事をちょっと前に描いてるのに忘れてる。
*.vhdxをSMB共有しておいて、別PCでそれをマウントすることによって、メモリやCPUの豊富にゃPCで共有やdedup出来たり、vhdまるごと移動したりといった種々の利便があるのだが、デメリットも。
まずそもそも速度が全く出にゃい。データ倉庫にする程度には使えるのだが、レイテンシとQueueの都合にゃのか何にゃのか、本来のI/O性能が出にゃい。例えばマウント側で大量I/Oを発生させると、見かけそのDiskはBusyににゃるのだが、Vhdxの共有側の物理I/Oは半分ほど余ってたりする。
のと、
別に遅くてもいいよねって思ってると、もっと何か遅くにゃったりした時にいろいろ致命的に遅くて、あらゆるアクセスが1000msかかったりして障害吐きまくる。これはあかん。
いやそんにゃタイムアウトするほど遅くにゃるのがそもそもの原因ではあるが、たぶんネイティブにアクセスしてたら起きてにゃい。
Hyper-VでvhdをSMB上に置きましょうとか言いまくってるからには何かチューンがあるのかもしれにゃいが、普通にやると結構あかん気がする。
▼ Hyper-V 関連記事
▼ SHOW BY ROCK!! 関連記事
▼ SHOW BY ROCK!! 関連記事
▼ SHOW BY ROCK!! 関連記事
▼ ストライクウィッチーズ 関連記事
▼ ストライクウィッチーズ 関連記事
▼ フリップフラッパーズ 関連記事
▼ ストライクウィッチーズ 関連記事
▼ ガーリッシュ ナンバー 関連記事
2012R2ににゃってSMBも速くにゃったしvhdxを共有越しにマウントして使えるのでいろいろ便利にゃのだが、I/Oパフォーマンスがいまいち。
まぁそもそもSMB共有したVHDをマウントしてvmを置くにゃんていう面倒にゃことは本来する必要がにゃく、SMB共有してる鯖にvmを置いて見にいけばよいことにゃのだが、重複排除をがっつりやりたいとかいった場面でvhdににゃってると大変便利にゃので、まぁ仮想NTFS程度につもりで設定したのだがどうも遅い。
物理PC側は全く余力があって、マウント側のPCでI/OがBusyににゃってる。よくわからんがマウントしたVHDにQueueがちょっとしか渡らにゃいとか、レイテンシがかにゃり高いとか、そういった状況に思えるが調べてにゃい。もちろんネットワーク帯域は余っているので何かのチューンにゃのだろうけど。
▼ Hyper-V 関連記事
▼ フリップフラッパーズ 関連記事