EMC VMAX3を使用しているバックエンドの同じデータセンターにある2つのサーバー間で(rsyncを使用して約7 TBのデータを)コピーしようとしています
約30-40GBのデータマルチパスをコピーした後、失敗する
Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: Recovered to normal mode
Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: remaining active paths: 1
Dec 15 01:57:53 test.example.com kernel: sd 1:0:2:20: [sdeu] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[root@test log]# multipath -ll |grep -i fail
|- 1:0:0:15 sdq 65:0 failed ready running
- 3:0:0:15 sdai 66:32 failed ready running
デフォルトのmultipath.confを使用しています
HBA driver version 8.07.00.26.06.8-k
HBA model QLogic Corp. ISP8324-based 16Gb Fibre Channel to PCI Express Adapter
OS: CentOS 64-bit/2.6.32-642.6.2.el6.x86_64
Hardware:Intel/HP ProLiant DL380 Gen9
既にこのソリューションを検証し、EMCで確認したところ、すべて問題ないようです https://access.redhat.com/solutions/4384
さらに詳しい情報
-ネットワーク側にドロップ/エラーパケットはありません。
すでに無効化されたTHP
echo never>/sys/kernel/mm/redhat_transparent_hugepage/enabled
発行時に収集されたVMcore
発行時にvmcoreを収集できます
KERNEL: /usr/lib/debug/lib/modules/2.6.32-642.6.2.el6.x86_64/vmlinux
DUMPFILE: vmcore [PARTIAL DUMP]
CPUS: 36
DATE: Fri Dec 16 00:11:26 2016
UPTIME: 01:48:57
LOAD AVERAGE: 0.41, 0.49, 0.60
TASKS: 1238
NODENAME: test.example.com
RELEASE: 2.6.32-642.6.2.el6.x86_64
VERSION: #1 SMP Wed Oct 26 06:52:09 UTC 2016
MACHINE: x86_64 (2297 Mhz)
MEMORY: 511.9 GB
PANIC: "BUG: unable to handle kernel NULL pointer dereference at 0000000000000018"
PID: 15840
COMMAND: "kjournald"
TASK: ffff884023446ab0 [THREAD_INFO: ffff88103def4000]
CPU: 2
STATE: TASK_RUNNING (PANIC)
Qlogic sidでデバッグモードをエンバリングした後
qla2xxx [0000:0b:00.0]-3822:5: FCP command status: 0x2-0x0 (0x70000) nexus=5:1:0 portid=1f0160 oxid=0x800 cdb=2a200996238000038000 len=0x70000 rsp_info=0x0 resid=0x0 fw_resid=0x0 sp=ffff882189d42580 cp=ffff88276d249480.
qla2xxx [0000:84:00.0]-3822:7: FCP command status: 0x2-0x0 (0x70000) nexus=7:0:3 portid=450000 oxid=0x4de cdb=2a20098a5b0000010000 len=0x20000 rsp_info=0x0 resid=0x0 fw_resid=0x0 sp=ffff882189d421c0 cp=ffff8880237e0880.
最後に問題は解決されました
エラー:技術プレビュー:DIF/DIXサポートは完全にサポートされていない可能性があります。
問題が発生している間、私は常にこのメッセージをdmesgで確認し、このメッセージを無視し続けました
さらにデバッグすると、カーネルが汚染された状態にあることがわかりました
cat /proc/sys/kernel/tainted **So it's a combination of TAINT_TECH_PREVIEW and TAINT_WARN**
536871424
lsmod |egrep -i "dif|dix"
crc_t10dif 1209 1 sd_mod
modinfo crc_t10dif
filename: /lib/modules/2.6.32-642.6.2.el6.x86_64/kernel/lib/crc-t10dif.ko
softdep: pre: crct10dif
license: GPL
description: T10 DIF CRC calculation
srcversion: 52BC47DEA6DD58B87A2D9C1
depends:
vermagic: 2.6.32-642.6.2.el6.x86_64 SMP mod_unload modversions
RedHatによる
DIFは、最近SCSI規格に追加された新機能です。一般的に使用される512バイトのディスクブロックのサイズを512から520バイトに増やします。追加のバイトは、データ整合性フィールド(DIF)を構成します。基本的な考え方は、HBAが書き込み時にデータブロックのチェックサム値を計算し、それをDIFに格納するというものです。ストレージデバイスは、受信時にチェックサムを確認し、データとチェックサムを保存します。読み取り時に、チェックサムはストレージデバイスと受信側のHBAによってチェックされます。
Data Integrity Extension(DIX)を使用すると、このチェックでスタックを上に移動できます。アプリケーションはチェックサムを計算してHBAに渡し、512バイトのデータブロックに追加します。これにより、完全なエンドツーエンドのデータ整合性チェックが提供されます
一部のベンダーは、DIF/DIX機能を参照するために保護情報(PI)という名前を採用しています。 LinuxのDIF/DIXに関連する1つの問題があります。メモリ管理システムは、書き込みのキューに入れられている間にデータバッファーを変更する可能性があります。これを行う場合、メモリ管理システムは、I/Oが成功した後、そのページをダーティとしてマークしておくことを忘れないでください。チェックサムの計算後、書き込みが完了する前にメモリ管理システムがバッファ内のデータを変更すると、チェックサムテストが失敗し、書き込みが失敗し、ファイルシステムが読み取り専用になるか、または同様のエラーが発生します。発生する。
このため、Red Hat Enterprise Linux 6のユーザーは次の点に注意する必要があります。DIF/DIXハードウェアチェックサム機能は、O_DIRECT I/Oのみを発行するアプリケーションでのみ使用する必要があります。これらのアプリケーションは、ローブロックデバイス、またはO_DIRECTモードのXFSファイルシステムを使用できます。 (XFSは、バッファリングされたIO特定の割り当て操作を実行するときにフォールバックしない唯一のファイルシステムです。)この機能を有効にする必要があるのは、O_DIRECT I/OおよびDIF/DIXハードウェアで使用するように設計されたアプリケーションのみです。
DIF/DIXはRHEL 6.0のTech Previewです。現在、このサポートを持つドライバーとHBAの組み合わせは、Emulex lpfcとLSI mpt2sasの2つだけです。 Netapp Engenio FC RAIDアレイ、および特定のHitachi SASディスクです。これをサポートするストレージベンダーはごくわずかです。将来、この機能をサポートするストレージベンダーが増えることを期待しています。
EMCを使用しているので、この機能を無効にすることを決定しました。
cat /etc/modprobe.d/qla2xxx.conf
options qla2xxx ql2xenabledif=0 ql2xenablehba_err_chk=0
Back up existing initramfs: cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
Rebuild initramfs: dracut -f -v
Verify that /etc/modprobe.d/qla2xxx.conf is the same as the one in initramfs (time and size should be the same): lsinitrd | grep qla2xxx.conf; ls -al /etc/modprobe.d/qla2xxx.conf
これは HP ProLiant DL380 Gen9 サーバーです。かなり標準的なエンタープライズクラスのサーバー。
サーバーのファームウェアリビジョンに関する情報を教えてもらえますか?
EMC PowerPathは実際にインストールされていますか?もしそうなら、 ここをチェック 。
HP管理エージェントがインストールされていますか?もしそうなら、あなたはhplog -v
の出力を投稿することができますか?.
ILO4ログで何か見ましたか? ILOはアクセス可能ですか?
システムのスロットに取り付けられているすべてのPCIeカードについて説明できますか?
RHEL6固有のチューニングについては、XFSを実行し、tuned-adm profile enterprise-storage
を実行して、ファイルシステムがマウントされていることを確認することを強くお勧めしますnobarrier
(調整されたプロファイルで処理する必要があります)。
ボリュームについては、/dev/sdX
ではなくdm
(マルチパス)デバイスを使用していることを確認してください。参照: https://access.redhat.com/solutions/12122
これまでに提示した内容と Redhatのサポートサイト (および ここでの説明 )にリストされているチェックを見ると、HBA障害の可能性を除外できません。 PCIeライザーの問題。また、VMAX側に問題がある可能性があります。
PCIeスロットを交換して再試行できますか?カードを交換して再試行できますか?
HBAのファームウェアは最新ですか?これが 2016年12月 からの最新パッケージです。
ファームウェア6.07.02 BIOS 3.21
DID_ERRORは通常、HBAから返されたデータ内の異常を介して、ドライバーソフトウェアが何らかのタイプのハードウェアエラーを検出したことを示します。
ハードウェアまたはsanベースの問題がストレージサブシステム内に存在するため、受信したファイバーチャネル応答フレームに、ドライバーが使用または調整できない無効な情報または競合する情報が含まれています。
システムのハードウェアを確認し、エラーカウンターなどを切り替えて、問題の原因がどこにあるかを確認してください。最も可能性の高い候補はHBA自体です。
これは、SFPの1つでソフト障害が発生したように見えます...大規模なコピーを実行しているときに、ストレージスイッチでポートのエラーを確認してください。
最近、似たような問題があり、すべてが問題なく見えました。サーバーベンダーは自社のものを承認し、ストレージベンダーは自社のものは良さそうだ、SFPはすべて問題ないと誓った... SFPは、MPIOインターフェイスを介して大量のデータが送信され、ストレージスイッチポートがログに記録され始めます。
すべてのファイバーケーブルを新しいケーブルに交換し、SFPをスペアと交換して、SFPに問題があることをベンダーに証明しました。
/ etc/sysconfig/mkinitrd/multipath MULTIPATH = [〜#〜] no [〜#〜] on MULTIPATH = [〜#〜]はい[〜#〜]およびfile /etc/multipath.confで-次のコメント:
自動ロードをオンにします。
モジュールのダウンロードをオンにします。
Autocfgの場合:
サーバーをリロードし、すべてを確認します。
マルチパスを見る: