以前組み立てたサーバーがあるのですが、RAIDにつかっているHDDがまずかったりといろいろと問題があるためサーバーを入れ替えていくことにしています。その第一歩としてファイルサーバーを新たに構築した上で旧のファイルサーバーからデータをそっくりそのままコピーしよう、ということで作業をやっています。新しいハードウェアに入れ替えたりLinuxを入れ替えたりするといろいろと環境が変わるのでその意味でも分からない人がいれば参考になるかな~と言うことで。
構築の前提条件について
ちょっと前提となる条件について見ていきます。
CentOS7を使うことに
RAID環境が組まれている関係で旧のファイルサーバーはOSのアップグレードをしないようにしていたためCentOS6.7だったわけですね。ここでCentOS7に入れ替えることでサービス関係がsystemctl経由に切り替わったりとするわけですね。このあたりはFedoraでバージョンアップをしてきたので作業には慣れているはずです。はい。
RAIDのHDDにはArchiveHDDを使うことに
旧のファイルサーバーもそれなりの領域を持っていたのでそれを上回り、かつ予算を抑えられるという条件が必要になってくるとRAIDのHDDとしてはArchiveHDDを使うほかはなかったのですよ・・・。なおArchiveHDDの紹介ページにもありますが、RAID使用は推奨されていません。まあ、RAID1ならば問題は無いのでしょうがそれだと(現段階では)8TBを超えられないですし。アクセス速度が低下してもいいならRAID0+1とかRAID5とかRAID6とかを使用するのもありだと考えています。もちろん、その領域は純粋なデータ領域でありOSのデータを格納するのは別のHDDにしなければさすがにまずいでしょうが・・・。
構築作業・・・でしたが・・・
と書いているとおり、実は一番最初につまずいて四苦八苦してしまいました。どういうことかはこれから書いていきます。
というかOSがインストールできないのは・・・パーティションの設定が原因
そう、これが今回の構築において最大の疑問点かつつまずいたポイントでした。前回と同じくあらかじめパーティションを切っておいてインストールしようとしたのですがこの方法ではインストールする前にパーティション構成の段階で問題あり、と判断されて処理が進行しない、という問題に。おそらく2.2TBを上回るHDDを使ったこととUEFIにからむ問題だとおもうのですが、OSをインストールするときに必ずブート領域(先頭に専用のパーティション(数MB)を設定し、その後ろに/boot(/efi)を置く(500MBくらい))が必要になります。これがないとCentOS7では起動処理ができません。さらにはデータ領域はすべてLVMで管理することが前提となっているため、残りの領域をすべてLVMで確保した上でパーティションをLVM上から切り出す、という設定を行わなければインストールができない、という状態になっています。これを知らなかったため初めの画面で四苦八苦しまくっていた、というわけです。初心者はほとんどの場合自動設定を使うので逆に嵌まらなかった、というわけですね。ちなみにCentOS7からデフォルトのファイルシステムはext4からxfsに変わっていますのでその辺も知らないと詰まることになりますよ。
LANのドライバがCentOS7についていなかったのでダウンロードしてビルドすることに
とりあえず最小環境でインストールできたので安心したのですがなんとLANが使えないという事態に驚きました。マザーボードの説明には「Intel GbE LAN chip」としか書いていなかったので何者?と思いましたが、いろいろと調べてみるとIntelのI219Vというものでかなり新しいチップだったために情報がなかったようです。仕方が無いので対応するドライバとしてe1000eを別PCでダウンロードしてビルド・・・ってビルドツールが入っていないのですが~~~ということを叫びながら。
ビルドツールはCentOS7をDVD経由でインストールした場合であればパッケージがDVDにありますのでyumでDVDを参照するリポジトリを一時的に登録してそこから開発ツール群をインストールしましょう。ビルドが完了してドライバをインストールできればLANが動くはずです。このあたりはこちらで書いていることに非常によく似た事をします。r8168の場合は競合していたので無効処理が必要でしたが今回は単純なインストールなのでまだましですね。組み終わったらdkmsも設定しておくと良いと思います。Fedoraの場合はdkmsはyumだけでインストールできますがCentOS7の場合はEPELのリポジトリが必要になるのでkernelを更新する前にリポジトリの登録=>dkmsインストール=>dkms設定までをやってしまうといいですね。
UEFIの設定によってはディスプレイが接続していないと起動しないという事態にも
キーボードが接続していないと起動しない、という設定は昔のBIOSの時代からよくありましたが、まさか「ディスプレイが接続していないとブート処理を行わない」なんていうことが今の時代だと起こりえるのだと知ってこちらもびっくりでした。しかもこれをすり抜ける設定が分からなくてマザーボードの説明書を見ながら何が対応しているのかを調べるのに時間がかかってしまいました。
ちなみにこれですが、私の場合ですとUEFIの設定でFastBootというオプションがあるのですが、これをわざと有効にしてVGAの認識確認を起動後まで遅らせる、という設定にすることですり抜けることが可能です。まさかFastBootを有効にしないとディスプレイを接続しないで起動ができないとは考えなかったので。そのほかUSB等の認識はOS起動前になるように設定した方が良いと思います。
Linuxの場合RAIDはチップセット経由よりソフトウェアで設定するのが良い気がする
はじめはチップセット側のRAIDの設定を利用するつもりだったのですが、dmraidの設定が面倒になった・・・のではなく、チップセットを使ったRAIDは結局のところOS側で制御される擬似的なRAIDなのでそれならばソフトウェアRAIDをLinux上で構築した方がステータスの閲覧などが簡単になるのでそちらの方がおすすめです。ファイルシステムについてもext4でもブロックサイズなどの設定をRAIDのチャンクサイズと合わせて設定する必要がありますが、xfsでも似たようなオプションがあるのでそれを指定してファイルシステムを構築すると速度低下は最小限に抑えられるはずです。・・・というかxfsの場合はちゃんとチャンクサイズ相当のオプションとRAIDの台数に該当するオプションがあるのにびっくりです。
SELinuxをONにしたまま使う場合はSambaのフラグを設定しよう
今回はSELinuxをONにしたまま使用する事にしてみました。Linuxサーバーを構築する大半のページではSELinuxをOFFにして・・・と書いてあるのですがじゃあ何のためのSELinuxなんだ?ということで疑問に思っていたわけですね。そのため今回はSELinuxをONにしたままサーバーの構築をする事にしました。httpもほとんど使わないですしね。
と思っていたらSambaでつまずきました。Sambaを使えるように設定しただけではSELinuxでアクセスがはじかれてしまうので各種フラグを解除してアクセスができるようにしないといけません。フラグに関してはおそらくこの辺ですか。
- samba_domain_controller
- samba_enable_home_dirs (ホーム領域にアクセスを許可する)
- samba_export_all_ro (ファイルの読み出しを全ての領域で許可する)
- samba_export_all_rw (ファイルの書き込みを全ての領域で許可する)
- smbd_anon_write (Sambaのファイルの書き込みを許可する)
これらのフラグをONにすれば問題は起こらないはずです。なお、作成したディレクトリの場合Sambaのアクセス権限がSELinux上でないこともありますのでそれを設定することも忘れずに。
Wineが使い物にならない
今回落胆した最大のポイント。理由はよく分かりませんがWineに初期環境を作らせた後ちょっと操作する(たとえばファイルをWineとは関係ない方法でコピーする)だけでマウントマネージャと呼ばれる内部のファイル管理システムがエラーを起こしてWineが認識するドライブにアクセスできなくなる、という状態に。おかげで旧ファイルサーバーでWineでやっていたことができなくなってしまいました。どうしましょうかね・・・。
GNOMEをインストールした場合はコンソールでのライセンス確認がある
Wineを使おうとしたときにVNC経由でアクセスすることになるとデスクトップ環境がいるのでGNOMEをインストールしたわけですが、ここでちょっと面白いことが。基本的に通信だけで制御していたのでそのときは何とも思わなかったのですが一度直接操作する必要があったのでディスプレイとキーボードをつないで起動してみるとログイン画面に大量の文字化けした何か怪しいものが出てきてびっくり。
まさかウィルスにでもやられたのか?と疑いましたがターミナルからアクセスすると何も起こっていないのでよく分からなくなり一度ロケールを英語圏に切り替えて(localectlを使います)再度起動してみると何のことはない。GNOMEを使用するためのライセンスの確認でした。無理に日本語で表示しようとしてコンソールが英語のみだったために起こった珍現象でした。そうと分かればライセンスを確認して許諾して一件落着、と。なお、ロケールは戻しておいた方が良いと思います。
CentOS7ではQSVが使用できる方法があるので後で試してみる
せめて活動しているところを見せなくては・・・ということでCentOS7でのQSVを後で試していろいろと書いてみたいと思います。毎度毎度メインマシンでエンコードしているのもリソースが取られるだけですからね。サーバーでのバッチエンコードができればメインから見れば楽になりますから。問題なのは参考ページによるとIntelMediaSDKがSkylakeに対応していない可能性があるところ。せっかく新しくしたのにその部分だけうまくいかないために失敗、というのは悲しいですからね。試す段階でMediaSDKがSkylakeに対応していることを願いたいところです。そうすればx265のエンコードがLinux上でQSV経由でできる・・・?