Ubuntu 11.04、ソフトウェアRAIDおよびそのリカバリを備えた仮想サーバー

こんにちはHabr。 Ubuntu Server 11.04でのソフトウェアRAIDの問題の解決策について説明したいと思います。サーバーの誤った再起動が発生しました。



数日前、私は働いて、PHPでコードを書いたが、オフィスサーバーはあまりロードしなかった。 一般的に、mysqlデータベースがサーバーから共有されない場合を除き、サーバーとクライアントの両方のコードをgitを使用して独自のマシンとバージョンで記述するのが一般的です。 そして、必要に応じて、git pushで救助します。 多くの開発では、サーバーはgitから更新され、インターネットからアクセス可能なvhostsで構成されます。



サーバーからいくつかのページをリロードすると、何かが間違っていること、ページの一部がロードされていること、そしてすべてが...と感じました。そして、sshの接続が落ちました。 Apacheがハングしただけではないことが明らかになりました。



「問題ではありません」と思いました。「仮想化があるので、vmを再起動します。これはすべての問題です。」 はい、そうです。 Ubuntu Server 11.04には物理サーバーがあり、qemuの下で別のUbuntu Server 11.04が実行されており、必要なすべてのサービスが構成されています。 なぜそう この決定は、経験の浅い同僚によって行われましたが、残念ながら辞めたので、システム管理に特に強くはありません。 パスワードの変更に関する話の一部は省略しますが、確かに知りませんでした:)



私は物理サーバーに接続し、そこに：

virsh: list
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

わかりました、ID 1のサーバーを実行しています。端末に固執していません（ちょっとしたパニックを考慮して、vncを忘れましたが、そのときはゲストOS用に構成されていましたが、あまり役に立ちません）。

 virsh: reboot 1 error: this function is not supported by the hypervisor: virDomainReboot
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

大丈夫ではありませんが、あなたは何ができますか：

 virsh: destroy 1 start 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

待っています。 まだ端末にしがみついていません。 ssh接続が機能しません。 Vobschemサーバーが起動しません。 複数の破棄/開始の試行が失敗しました。 必死、私はゲストOSの構成を見ることにしました。 そしてそこに：

 <graphics type='vnc' port='5901' autoport='no' listen='0.0.0.0'/>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はvncでこの不名誉を見て喜んで登りました。 さらにすべてはゲストOS内で実行されます。 そしてそこに：

 The disk drive for /some/mounted/folder is not ready yet or not present Continue to wait; or Press S to skip mounting or M for manual recovery
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Sの最初のプレスの後、私はすべてが非常に悪いように見えることに気付きました。 Sを1秒間押し続けてSを500回押すと、OSは起動し続けましたが、/ var / lib / mysqlなどのフォルダーがマウントされなかったため、mysql、apache、および他の多くのデーモンは起動しませんでした。 ログインを克服して、すべてがなくなった場所を理解しようとしました（バックアップはありますが、復元するために残りの週は本当にやりたくありませんでした）。 / etc / fstabおよび/ dev / like / dev / md / 1_0に奇妙なエントリが存在すると、私は不安になりました。 Googleは、これらがソフトウェアRAIDアレイの一部であることを提案しました。 Ubuntu内、Ubuntu、UbuntuソフトウェアRAID内...こちら。 5つのパートがありました。



Googleはfsckとmdadmが私を助けることを提案しました：

 fsck –nvf /dev/md/1_0 … fsck –nvf /dev/md/5_0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルシステムが破損しているとマークされていない場合でも、fsckには何も変更せず、興味深い情報の大量のガベージをコンソールに出力し、すべてをチェックするように依頼します。 5、3のうちFSエラー/損傷であることが判明しました。



それから私はチャンスを取り、それを修正するためにfsckに依頼しました：

 fsck –vf /dev/md/1_0 … fsck –vf /dev/md/1_0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時に、すべてのデバイスのmdadmは次のように述べました。

 mdadm --detail /dev/md/1_0 … Raid Level : raid1 …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/ etc / fstabのコメント：

 … /dev/md/1_0 /var/www ext3 defaults,noatime 1 2 …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

修正はバタンと行きました。 すべてを再びまとめる方法を理解することは残っています。 再起動は役に立ちませんでした。 アレイ自体は組み立てられていません。 / dev / md / [yyy]の/ dev / md [xxx]という形式のデバイスの名前とマッピングは、リブートごとに変更されました（/ dev / md [xxx]へのシンボリックリンクは/ dev / md /に作成されます）。 したがって、/ etc / mdadm.confに登録されたデバイスはシステムによって検出されず、自動的にマウントされませんでした。



この段階で、「以前はどのように働いていたのか？」と考えるのをやめ、そしてこのファイルに書かれた内容を/ dev / md /で見たものと関連付ける方法を断固として探し始めました。



それでも、私は見つけた：

 mdadm --detail /dev/md/123_0 … UUID : 4e9f1a60:4492:11e2:a25f:0800200c9a66 … less /etc/mdadm.conf ARRAY /dev/md/1_0 level=raid1 metadata=0.90 num-devices=2 devices=/dev/sda5,/dev/sdb5 UUID=4e9f1a60:4492:11e2:a25f:0800200c9a66
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

接続が見つかりました（UUID）、小規模の場合。 / etc / fstabにある古いマウントポイントを、/ dev / md [xxx]のリストから新しいデバイスに割り当てます。

 mount –a #    /etc/fstab
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

mysql、Apacheなどを再起動した後、/ var / wwwの内容が返され、すべてが咲いて踊っていることを見て、落ち着いてコーヒーを飲みに行きました。 判明したように、サーバーは稼働時間の4日前には稼働していませんでした。 ただし、問題が100％解決されたとは言えません。 再起動中の理解できない動作ですが、今ではすべてが再び機能するように実行する必要がある操作のリストがあります。 コミュニティへの質問ですが、似たようなものに出会いましたか？



この質問で、私の話を終わります。 ヒント、質問、コメントを歓迎します。



PS：上記の作業の後、ディスクの奇妙な構成であるこのような厄介な問題を取り除きたいと思いましたが、仮想化はそのままにしました。 同時に、サーバー構成スキルを開発し、当局にハードウェアに関する苦情のないサーバー（Dell PowerEdgeタワー）のメモリをアップグレードするよう依頼する機会があります。