サーバーを操作する重要なケース

サーバーハードウェアを含むすべての機器は、予期せず動作することがあります。 この機器が新品であるか、それとも数年間全負荷で動作しているかはまったく関係ありません。



失敗と誤動作の多くのケースがあり、問題の診断はしばしば刺激的なパズルに変わります。



以下に、いくつかの興味深い、重要なケースについて説明します。

トラブル検出

問題の登録は、顧客がチケットシステムを介してテクニカルサポートに連絡した後に最も頻繁に発生します。



固定構成の専用サーバーを当社からレンタルするクライアントの場合、問題がソフトウェアの性質ではないことを確認するために診断を実施します。



クライアントは通常、ソフトウェアの問題を自分で解決しますが、いずれにしても、システム管理者の支援を提供しようとします。



問題がハードウェアであることが明らかになった場合（たとえば、サーバーがRAMの一部を認識しない場合）、この場合、常に同様のサーバープラットフォームが用意されています。



ハードウェアの問題が検出された場合、障害が発生したサーバーからバックアップサーバーにディスクを転送し、ネットワーク機器を少し再構成した後、サーバーが起動します。 したがって、データは失われず、ダウンタイムは治療時から20分を超えません。

問題と解決策の例

サーバーのネットワーク障害

障害が発生したサーバーからバックアップサーバーにディスクを転送した後、サーバー上のネットワークが機能しなくなる可能性があります。 これは通常、DebianやUbuntuなどのLinuxファミリオペレーティングシステムを使用している場合に発生します。



実際のところ、オペレーティングシステムの初期インストール中に、ネットワークカードのMACアドレスは/etc/udev/rules.d/70-persistent-net.rulesにある特別なファイルに記録されます。



オペレーティングシステムが起動すると、このファイルはインターフェイス名をMACアドレスにマッピングします。 サーバーをバックアップサーバーに置き換えると、ネットワークインターフェイスのMACアドレスが一致しなくなり、サーバーでネットワークが動作しなくなります。



問題を解決するには、指定したファイルを削除してネットワークサービスを再起動するか、サーバーを再起動する必要があります。



このファイルが見つからないオペレーティングシステムは、同様のファイルを自動的に生成し、インターフェイスをネットワークカードの新しいMACアドレスにマップします。



この後のIPアドレスの再構成は必要ありません。ネットワークはすぐに動作を開始します。

フリーズに関するフローティング問題

かつて、運用中のランダムなフリーズの問題を診断するためにサーバーがやってきました。 BIOSおよびIPMIログをチェックしました-空、エラーなし。 彼らはストレステストを行い、すべてのプロセッサコアに100％の負荷をかけ、同時に温度制御を行いました。30分間の動作後はしっかりとハングします。



同時に、プロセッサは正常に機能し、温度は負荷がかかった状態で標準温度を超えず、すべてのクーラーは正常に機能していました。 問題が過熱ではないことが明らかになりました。



次に、RAMモジュールの可能性のある障害を除外する必要があったため、かなり人気のあるMemtest86 +を使用してサーバーをメモリテストしました。 約20分後、サーバーは期待どおりにフリーズし、RAMモジュールの1つでエラーが発生します。



モジュールを新しいものと交換して、サーバーを再びテストしましたが、大失敗に直面しました-サーバーが再びクラッシュし、別のRAMモジュールでエラーが発生しました。 彼を置き換えました。 別のテスト-再びクラッシュし、再びRAMにエラーが表示されました。 RAMスロットを詳しく調べても、欠陥は見つかりませんでした。



問題の原因の可能性が1つ残っています-中央処理装置。 実際には、RAMコントローラーはプロセッサー内に正確に配置されており、故障する可能性があるのは彼でした。



プロセッサを取り外したところ、大惨事を発見しました-ソケットの1つのピンが上部で破損しており、ピンの破損した先端が文字通りプロセッサの接触領域に突き刺さっていました。 その結果、サーバーに負荷がかかっていないときにはすべてが適切に機能していましたが、プロセッサーの温度が上昇すると接続が切断され、RAMコントローラーの通常の動作が停止してハングアップしました。







最後に、マザーボードを交換することで問題が解決しました。残念ながら、壊れたソケットのピンを復元することはできません。これはすでにサービスセンターのタスクです。

OSのインストール時に仮想サーバーがハングする

機器メーカーがハードウェアのアーキテクチャを変更し始め、新しいテクノロジーを優先して古いテクノロジーをサポートすることを拒否し始めると、かなりおかしなケースが発生します。



Windows Server 2008 R2オペレーティングシステムをインストールしようとしたときに、サーバーがフリーズするという苦情が寄せられました。 インストーラーが正常に起動した後、サーバーはKVMコンソールのマウスとキーボードへの応答を停止しました。 問題を特定するために、彼らは物理的なマウスとキーボードをサーバーに接続しました-すべては同じで、インストーラーは入力デバイスへの応答を開始および停止します。



当時、このサーバーはSupermicro X11SSL-fマザーボードをベースにした最初のサーバーの1つでした。 BIOS設定では、Windows 7の興味深いインストール項目が無効に設定されていました。 Windows 7、2008、および2008 R2は同じインストーラーに展開されるため、このオプションを[有効]に設定すると、マウスとキーボードが最終的に機能します。 しかし、これはオペレーティングシステムのインストールに関する叙事詩の始まりに過ぎません。



さらに、インストールするドライブを選択したときに、単一のドライブが表示されず、さらに、追加のドライバーのインストールを必要とするエラーが発行されました。 オペレーティングシステムはUSBスティックからインストールされ、インターネット上のクイック検索で、インストールプログラムがUSB 3.0コントローラーのドライバーを見つけられない場合にこの効果が発生することが示されました。



ウィキペディアは、BIOSでUSB 3.0サポート（XHCIコントローラー）を無効にすることで問題が解決したと報告しました。 マザーボードのドキュメントを開いたとき、サプライズが待っていました-開発者は、XHCI（eXtensible Host Controller Interface）を優先して、EHCIコントローラー（Enhanced Host Controller Interface）を完全に放棄することにしました。 つまり、このマザーボードのUSBポートはすべてUSB 3.0ポートです。 また、XHCIコントローラーをオフにすると、入力デバイスも無効になり、サーバーを操作できなくなり、それに応じてオペレーティングシステムをインストールできなくなります。



サーバープラットフォームにはCD / DVDディスクを読み取るためのドライブが装備されていなかったため、唯一の解決策は、ドライバーをオペレーティングシステムの配布システムに直接統合することでした。 USB 3.0コントローラードライバーを統合し、インストールイメージを再構築することによってのみ、このサーバーにWindows Server 2008 R2をインストールすることができました。このケースはナレッジベースに入ったため、エンジニアは無駄な試みに時間をかけすぎません。

Dell PowerVaultの興味深い機能

お客様が宿泊施設に私たちの機器を持ち込む場合、さらに楽しいケースがありますが、期待どおりに動作しません。 これは、ディスクエンクロージャーのDell PowerVaultラインで起こったこととまったく同じです。



デバイスは、iSCSIプロトコルで動作する2つのディスクコントローラーとネットワークインターフェイスを備えたデータストレージシステムです。 これらのインターフェースに加えて、リモート制御用のMGMTポートがあります。







ホスト機器向けのサービスには、「追加の10 Mbpsポート」と呼ばれる特別なサービスがあります。これは、リモートサーバー管理ツールを接続する必要がある場合に注文されます。 これらのファンドには異なる名前が付いています。

• Hewlett-Packardによる「ILO」。
• デルの「IDrac」。
• SupermicroのIPMI。

それらの機能はほぼ同じです-サーバーの状態とリモートコンソールへのアクセスを監視します。 したがって、彼らは高いチャネル速度を必要としません-10 Mbit / sは快適な作業に十分です。 クライアントが注文したのはこのサービスです。 適切な銅接合を配置し、ネットワーク機器のポートを構成しました。



速度を制限するために、ポートは単純に10BASE-Tとして構成され、最大速度10 Mbpsで作業に含まれています。 すべての準備が整った後、ディスクシェルフのMGMTポートを接続しましたが、クライアントはすぐに、何も機能していないと言いました。







スイッチポートのステータスを確認したところ、「Physical link is down」という不快な碑文が見つかりました。 この碑文は、スイッチとそれに接続されているクライアント機器間の物理的な接続に問題があることを示しています。



圧着が不十分なコネクタ、破損したコネクタ、ケーブルの破損したコア-これは、リンクの不足を正確に引き起こす問題の小さなリストです。 もちろん、当社のエンジニアはすぐにツイストペアテスターを使用して接続を確認しました。 すべてのコアに電話がかけられ、ケーブルの両端が完全に圧着されました。 さらに、このケーブルにテストラップトップを含めたため、10 Mbpsの速度の接続ができたはずです。 問題はクライアントの機器側にあることが明らかになりました。



私たちは常にお客様が問題を解決できるように努めているため、リンクの欠如の正確な原因を突き止めることにしました。 MGMTポートコネクタを慎重に検討しました。すべて順調です。



製造元のWebサイトで元の操作手順を見つけて、ソフトウェア側からこのポートを「返済」できるかどうかを明確にしました。 しかし、そのような機会は提供されませんでした-いずれにせよ、ポートは自動的に上昇します。 このような機器は常にAuto-MDI（X）をサポートする必要があるという事実にもかかわらず、つまり、どのケーブルがオンになっているかを正しく判断します：通常またはクロスオーバー、クロスオーバーを圧縮してスイッチの同じポートに接続する実験を行いました。 スイッチポートでデュプレックスパラメータを強制しようとしました。 効果はゼロでした-リンクはなく、アイデアはすでに終了していました。



ここで、エンジニアの1人は、この機器が10BASE-Tをサポートせず、100BASE-TXまたは1000BASE-Xでも動作するという常識の前提にまったく反しました。 通常、最も安価なデバイスであっても、どのポートも10BASE-Tと互換性があり、最初はエンジニアの想定は「フィクション」として却下されましたが、絶望のためにポートを100BASE-TXに切り替えてみることにしました。



私たちの驚きは際限なく、リンクはすぐに上昇しました。 MGMTポートで10BASE-Tがサポートされていない理由は、謎のままです。 そのようなケースは非常にまれですが、あるべき場所があります。



クライアントは私たちよりも驚かず、問題を解決してくれたことに非常に感謝しました。 したがって、彼らは100BASE-TXでポートを離れ、組み込みの速度制限メカニズムを使用してポートの速度を直接制限しました。

冷却タービンの故障

クライアントが私たちのところに来たら、サーバーを取り外してサービスエリアに持って行くように頼みました。 エンジニアはあらゆることを行い、機器を彼に残しました。 1時間経過、2番目、3番目-クライアントは常にサーバーを起動/停止し、問題は何かを尋ねました。



Hewlett-Packardサーバーは6つの冷却タービンのうち2つに障害が発生したことがわかりました。 その後、サーバーの電源が入り、冷却エラーが発生し、すぐにシャットダウンします。 同時に、重要なサービスを備えたハイパーバイザーがサーバー上にあります。 サービスの通常の操作を復元するには、仮想マシンを別の物理ノードに緊急に移行する必要がありました。



次のようにクライアントを支援することにしました。 通常、サーバーは、回転数を読み取るだけで、冷却ファンですべてが正常であることを理解します。 同時に、もちろん、Hewlett-Packardのエンジニアはすべてを行ったため、元のインペラをアナログ（非標準コネクタ、非標準ピン配列）に交換することは不可能でした。



このような部品のオリジナルは約100ドルで、購入して購入することはできません。海外から注文する必要があります。 幸いなことに、インターネット上で、元のピン配置の回路を発見し、ピンの1つが1秒あたりのエンジン回転数を読み取るだけであることがわかりました。



さらに、それは技術的な問題でした-彼らはプロトタイピングのために数本のワイヤーを取り（偶然手にいました-私たちのエンジニアの一部はArduinoが好きです）、壊れたコネクターで隣接する稼働中のタービンのピンを接続しました。 サーバーが起動し、クライアントは最終的に仮想マシンを移行し、サービスを開始しました。



もちろん、これはすべてクライアントの責任の下でのみ行われましたが、その結果、そのような非標準的な動きにより、ダウンタイムを最小限に抑えることができました。

そして、ディスクはどこにありますか？

場合によっては、問題の原因が非常に重要であるため、発見に非常に長い時間がかかることがあります。 そして、クライアントの1人がランダムなディスクダンプとサーバーのハングについて不満を言ったときに起こりました。 ハードウェアプラットフォームは、847（4Uフォームファクター）の場合は36個のドライブを接続するためのバスケットを備えたSupermicroです。 3つの同一のAdaptec RAIDコントローラーがサーバーにインストールされ、それぞれに12台のドライブが接続されました。 問題発生時に、サーバーはランダムな数のディスクの表示を停止し、クラッシュしました。 サーバーは実稼働から除外され、診断を開始しました。



最初に発見されたのは、1つのコントローラーだけでディスクが落ちたことです。 同時に、「ドロップされたディスク」はネイティブのAdaptec管理ユーティリティのリストから消え、サーバーが完全にオフになってから再び接続されたときにのみ再表示されました。 最初に思いついたのは、コントローラーソフトウェアです。 3つのコントローラーのファームウェアはわずかに異なるため、すべてのコントローラーに1つのバージョンのファームウェアをインストールすることにしました。 サーバーを最大負荷モードで実行し、実行しました-すべてが期待どおりに動作します。 問題を解決済みとしてマークすると、サーバーは実稼働中のクライアントに戻されました。



2週間後、再び同じ問題を処理します。 コントローラーを同様のものと交換することにしました。 完了、点滅、接続、テスト開始。 問題は残っています-数日で、すべてのディスクが新しいコントローラー上で落下し、サーバーが安全にフリーズします。



別のスロットにコントローラーを再インストールし、コントローラーからバックプレーンへのバックプレーンとSATAケーブルを交換しました。 1週間のテストとディスクの再落下-サーバーが再びフリーズしました。 Adaptecのサポートに連絡しても結果は得られませんでした。3つのコントローラーすべてをチェックしても問題はありませんでした。 マザーボードを交換し、プラットフォームをほぼゼロから再構築しました。 わずかな疑念を引き起こしたものはすべて新しいものに置き換えられました。 そして問題が再発しました。 ミステリーとのみ。



この問題は、各ディスクを個別にチェックし始めたときに偶然解決されました。 特定の負荷で、ディスクの1つが頭を叩き始め、SATAポートに短絡を与えましたが、アラーム表示はありませんでした。 コントローラーは同時にディスクの一部を見るのをやめ、電源で再接続したときにのみディスクの一部を認識し始めました。 これは、単一の障害ディスクがサーバープラットフォーム全体をクラッシュさせる方法です。

おわりに

もちろん、これはエンジニアが解決した興味深い状況のほんの一部です。 特にログに失敗のヒントがない場合、いくつかの問題を「キャッチ」するのは簡単ではありません。 しかし、このような状況では、エンジニアはサーバーハードウェアを完全に理解し、問題に対する最も多様なソリューションを見つけることを奨励します。



このようなおかしなケースは、私たちの練習にありました。

そして、あなたは何に遭遇しましたか？ コメントへようこそ。