T Ban

DWHシステムの再構築プロジェクトに参画した。私の参画はプロジェクト終盤であり、リリース後にトラブルが頻発していたためにその解決のために関わった。 内容は設計通りに動作していないソフトウェアの設定見直しとその試験、障害発生時の調査と復旧である。 　設定漏れや設計の不備が多数あり、私の担当範囲は一度設計書から再検証して設計から順に不備を是正していった。 　問題はデータベースのバックアップで発生していた。土日に停止させ、データベースの専用ツールを用いて物理バックアップを取得することになっていた。しかし、構築時の試験では30時間程度で完了していたバックアップが、リリース後のバックアップでは土日中に完了しなくなった。 　データベースのバックアップに使用する専用ツールは、リストアに必要なデータだけを選定して圧縮し、指定のパスに配置するだけの単純なツールであった。ファイルの配置であるが、LinuxのデータベースサーバがWindowsのCIFSサーバをマウントしており、そこにファイル配置を行う。WindowsのCIFS共有は別のiSCSI接続されたデータベースのバックアップ専用のSANストレージ上の領域を使用しており、Linuxデータベースサーバから転送されたデータはWindowsファイルサーバがストレージへ転送することになる。 構築時のパフォーマンス試験データがなかったため、適当なファイルを転送するなど動作を確認しながら調査した結果、何点か異常が見つかった。 　まず、ファイルの転送ごとに転送速度にばらつきがあったことからハードウェア障害を疑ったが、特に問題なく、更に調査したところスイッチのパケットドロップ数が多かった。結果、ステータス上はリンクアップしいたが、ケーブルが完全に挿さってなかったことを突き止め、挿しなおして解決した。 　次に設定を見直したところ、WindowsサーバーのSMBプロトコルのバージョン指定がなぜか古いものになっていたため、この修正も行った。 　更にWindowsファイルサーバ・SANストレージ間をパケットキャプチャしてiSCSI通信の状態を確認してみると、実際のデータ転送とは無関係なiSCSIの管理用のパケットが大量に検出された。しかもファイルの転送量が多くなるほど、管理用パケットの割合が増えていた。同じデータ内容のiSCSIのWrite命令を行うパケットが大量に出ており、リトライが何度も行われているようであった。ベンダーサポートに問い合わせたところ、機器内部状態が異常状態になっていた。これは通常の手段では復旧できない問題であった為、お客様への依頼・調整の上、機器を再度初期化して再構築し、異常状態は解決できた。 　その後再度データベースバックアップを行ったところ、想定の時間通りで完了できることを確認した。 【 使用した技術 】 vCenter6.5、ESXi6.5、Windows Server 2012 R2、BackupExec、ApplicationManager、PostgreSQL