安価なNICモジュール、蟹さんで有名な Realtek RTL8111/8168 ですが、これのLinuxドライバはopenではないので、メーカー配布のドライバを入れなければ鳴りません。ドライバを入れると、結構安定しています。(昔と比べれば)

elrepo の kmod-r8168 がメンテナンスもされていてお薦めです。EL5,6 のモジュールも別ディレクトリにあります。

ここで使われているのが、kmod という仕組みで、モジュールに、モジュールがコンパイルされたときのカーネルAPI(kABI)の情報が入っています。新しいカーネルをインストールすると、API互換性チェックが行われ、モジュールが(表面上は)使えるとわかると、 /lib/modules/(新カーネル)/weak-updates/ にシンボリックリンクが作られ、depmod すれば、モジュールがそのまま使い回せます。
(APIに手が加わると、API情報が合わなくなるので、kmod-xxxx の src.rpm から再構築が必要です。)

もう一つの方法が dkms で、起動時に毎回カーネルモジュールを build する方法です。カーネル更新後の再起動時にコンパイルする時間がかかりますが、確実にロードされます。

ところで、この kmod-r8168 は、多く使われる Realtek RTL8111/8168 シリーズ用ドライバモジュールとして、なぜか姉妹機種の r8169 がロードされてしまう問題への解決策です。r8169 は r8168 と基本部分の設計が同じなので、見かけ上動いてしまうのですが、DMAやオフロードなどの細かい違いの部分が問題になったときにエラー対処が異なっているので、一度問題が発生すると途端に動かなくなってしまいます。ちょっとの差なら、組込の r8169ドライバが r8168 もきちんとハンドルしてくれれば良いのですが、何年もサポートしてくれないあたり、何か特許やライセンスが絡んでいるのか、誰も興味が無いのか…(それなりにユーザはいるはずですが)

kmod-r8168 を入れても、Jumbo frame がうまく動かないという話をよく見かけます。もともと RTL の DMAやオフロード周りは動作が怪しいので、jumbo frame はお薦めできません(効果も限定的ですし)が、型番によって、チップが対応している最大サイズが異なります。ドライバ側ではこれを超える値も設定手来てしまう(?)ので、ご注意下さい。型番は、lspci, dmidecode, dmesg といったコマンドではわからないので、メーカの Specification を読んでください。

Jumbo Frame 最大サイズ
RTL8168B/8111B – 4kB
RTL8168C/8111C – 6kB
RTL8168CP/8111CP – 6kB
RTL8168D/8111D – 9kB
RTL8168DP/8111DP – 9kB
RTL8168E/8111E – 9kB
RTL8168EP/8111EP – 9kB
RTL8168E-VL/8111E-VL – 9kB
RTL8168F/8111F – 9kB
RTL8168G/8111G – 9kB
RTL8168H/8111H – 9kB

9kB が一般的な 9000バイトなのか、9kiB(9126バイト)なのかイマイチ不明です。ソースコードをぱっと見た限りは、9kB(9216バイト)で定義されているように見えますが、ドライババッファサイズとハードウエアの実装が一致するとは限りません。また、これが MTU として、ヘッダの40を引いた値を設定しないといけないのかもしれません。安定しない人は試してみて下さい。上限9216バイトなら、ヘッダを含めない値だとしても、MTU 9000 で安定して欲しいところですが。。。

Jumbo Frame 安定しないけど jumbo frame したい人のMTUサイズ
RTL8168B/8111B – 3960
RTL8168C/8111C – 5960
RTL8168D/8111D以降 – 8960

この2月に、広島大学情報メディア教育研究センター・総合科学研究科情報システム講座の中村純教授の研究室に、量子色力学計算用の演算サーバと、データの長期保管用ストレージサーバを納めさせて頂きました。

高性能演算器としては、GPGPU と Xeon Phi が選択肢に上がったのですが、計算の詳細を伺って、Xeon Phi のほうが適していると判断し、Intel Xeon E5 v2 のデュアルソケットに、Intel Xeon Phi 5110P を4枚搭載可能な構成を提案させて頂きました。初期段階として、Xeon Phi を2枚搭載したモデルを構築し、計算能力が不足し始めたら4枚に増設予定です。合わせて 2.2TFLOPS(4枚拡張時は4.2TFLOPS) のピーク性能がありスーパーコンピュータ並みの演算性能があります。コストの許す範囲内で、十分なバスレーンやCPUと演算器のバランス、拡張性など、総合的に良い構成にできたのではないかと思います。

GPGPUと同様に、Xeon Phi も、そのパフォーマンスを引き出すには専用のチューニングは必要です。中村教授は、IBM Cell B.E. での計算実績もあり、Phi でも GPU でもチューニングについてはお手の物だと思うのですが、格子計算は、隣接領域の計算結果がすぐに必要なケースが生じるため、多スレッドでメモリアクセスのレイテンシを隠蔽する GPU よりも、高度なキャッシュ制御でコア間の接続の強い Phi のほうが適していると判断しました。この選択が良い方向に働いてくれることと信じます。

中村教授は、計算が困難だと言われてきた有限密度の量子色力学場の格子計算において、世界を代表する物理学者の一人です。1995年の米国スーパーコンピューティング95で、日本グループ初となるゴードンベル賞を受賞されるなど、常に最先端で独創的な計算技法を取り入れ世界をリードされてきました。そんな中村教授の研究に用いる計算機群に、弊社のサーバ群を選んで頂いて、大変光栄です。演算能力では限界がありますが、環境作りではどこにも負けない設定に仕上げたつもりです。今後、この計算機から多くの成果が出てくることを期待します。

演算器以外でも、サーバグレードの冗長電源、冗長HDD構成で、故障の多い電源やHDDのトラブルでは簡単に停止しないような構成にしてあります。この手の計算機では、故障時にすぐに修理用の部品が調達できないこともあるので、多少の故障では止まらない事も重要と判断しました。計算機屋のできることは限られていますが、最大限研究をサポートできる環境作りを目指しています。このような案件のご相談もお受けできますので、遠慮無くご相談下さい。

Red Hat To Help Develop CentOS というニュースがありました。RedHat Enterprise Linux と互換性の高いディストリビューション CentOS の開発を、RedHat のスタッフがサポートする体制を作るとのことです。

CentOS は、RHEL から商標権などの問題のある部分を取り除く形で作られているので、予めその作業がしやすいような開発や管理が行われるようになるかもしれません。CentOS のユーザは、潜在的には RHEL の顧客になり得るため、CentOS を含めた RHEL派がより多くのシェアを獲得することは、RedHat 社の利益にも繋がるという判断でしょうか。

RHEL の多くの部分はオープンコミュニティで開発された成果であり、それを再配布することは(商標権などの問題を除いて)認められていますが、RedHat が、それをどのように見ているかは諸説ありました。最近は、カーネル(RedHatが配布するカーネルは、独自の拡張や修正が山のように当てられている)のパッケージングで、再配布を困難にするような変更があったりと、必ずしも快く思ってないのではないかという懸念もあったため、今回、このような形で正式に互換ディストリビューションの存在をサポートする態度が見られたのは、互換ディストリビューションの長期的なリリースの安定性には大変大きな好材料です。

CentOS は、単に RHEL互換というだけでなく、centosplus という独自拡張リポジトリも運営しており、積極的な独自拡張も行われていて、便利なだけでなく、面白いコミュニティでもあるのですが、資金面を中心に運営が危ぶまれたこともあるので、今回の RedHat の公式サポートは、非常に心強いニュースです。

弊社では、RHEL に相当する環境として、CentOS・Scientific Linux 環境の構築・管理なども行っておりますので、興味のある方はご相談下さい。

RedHat Enterprise Linux 7 の β版が発表されました。(記事)

fedora 19、kernel 3.10 がベースになるようで、サーバ・仮想化向けのアップデートが目立ちます。

Web 屋さんとして一番怖いのは php のバージョンアップかもしれませんね。fedora-19 をそのまま継承しているとすれば、php のバージョンは php-5.5 になります。
基本的には、現在の php-5.3 から大きな変更は無いはずですが、そのまま動くかどうか怪しいですよね。

RedHat Enterprise Linux 6.5 が登場しました。(記事)

主に基幹・大規模サーバ用の変更が目立ちますが、SL,CentOS に降りてきたら、小規模サーバでの変更点も見ていきたいです。

6.3 → 6.4 の時に、XFS+NFS4 の環境で kernel panic が出る不具合が入ったことがあったので、今回も自動アップデートには勇気が要りますね。
通常は RHEL の安定性には定評があるので、アップデートに躊躇することは少ないのですが。

ちょっと気になっているのが、php のバージョンです。
php 5.3 は開発元がサポートを打ち切って、RedHat が独自にパッチを当ててセキュリティ対策をしているのですが、これが 5.5 等になると、古い php アプリ/フレームワーク が動作しなくなる恐れがあります。
これは、6.x ではバージョンが維持されても、RHEL7 ではバージョンアップされるでしょうから、大きなシステムを運用されている方には頭が痛いかも。

ー追記ー

php は php-5.3.3-26 のようです。カーネルも kernel-2.6.32-431 のようですが、RHEL はカーネルに多くの機能をバックポートしてくれるので、バージョン番号が当てになりません。

Linux Kernel 3.0.x の Long-Term Support が終了し、elrepo の kernel-lt も、3.10.x 系列に変わりました。
3.0 から 3.10 までに何があったかを軽くまとめてみると、

• HDDへのライトバックキャッシュの最適化(3.1など)
• TCP周りの最適化(3.5など)
• ファイルシステム周りの変更(3.8など)
• 時分割でないマルチタスク(3.10)

特にファイルシステム周りでメタデータへのチェックサム付加などの変更がはいっているので、一度新しい kernel で mount してしまうと、古い kernel で読めなくなってしまうのではないかという心配が少しあります。
また、タスク切り替えの再設計は、かなりインパクトの大きな変更点だと思えるのですが、多スレッド環境でどのような変化があるのか楽しみです。