雲から地面へ：Proxmoxをロシア連邦のオフィスのコンピューターに移動する

こんにちは、Habr！



1つのProxmoxベースの仮想化サーバーをヘッツナーからロシア連邦に移動し、会社のオフィスのラックにある仮想化サーバーに移動した簡単な歴史に注目したいと思います。

Proxmoxを選択する理由とその機能について簡単に説明します。Proxmox仮想化システムに関するウィキペディア。



アクションの順序を復元せず、実際には以下の記事にある落とし穴に時間を無駄にしないように、自分自身と希望する人へのガイドとして投稿されています。



つまり、主な要望は、実行中のプロジェクトを管理する必要がないことです。セキュリティパッチがリリースされた場合にのみ、更新の必要はありません。 Webインターフェイスのシンプルさ。同社のスタッフには本物のLinuxの第一人者がいないためです。したがって、実用的なDebian標準は、Proxmoxを支持してすべての質問を決定しました。もう1つの利点は、仮想化カーネルによるプロセッサの負荷が低いことです。これは本当にそうです。



私はシステムを賞賛しました、私はカットの下で残りを求めます。



ユーロ為替レートの上昇に伴い、特別にレンタルしたサーバーで遠隔地の職場を提供するためのレンタルサービスの価格が上昇し始めました。計算の結果、物理構成で「プロセッサ8 x AMD Ryzen 5 1400クアッドコアプロセッサ（1ソケット）」、PCI-Eポートに取り付けるための2 * SSD M.2 1TB +ライザー、32 GbRAMを購入することが決定されました。 ..。クラウドでは、同じマシンCPU（s）8xIntel®Core（TM）i7 CPU 920 @ 2.67GHz（1ソケット）、2 * 2TB HDD、47.16GbRAM。





すぐに使用できるProxmoxストレージ設定はLVMボリュームに基づいていますが、イメージストレージにOSフォルダーやその他のファイルシステムオプション、さらには外部FTPリソースを使用することもできます（これについては以下で詳しく説明します）。このマシンでは、「data」という名前のLVMパーティションがディスク1に構成され、「data」という名前のproxmoxデータストアが登録され、仮想マシンのディスクイメージが格納されます。仮想マシンのバックアップ（スナップショット）は、特定のスケジュールに従って2番目のディスクに保存されます。



クラウドでは、2つのクライアントノードが、それぞれ16GBのRAMを備えた4つのCPUとcore2duoプロセッサタイプで起動されます。彼らの仮想ディスクは完全に2TBです。





移動するには、ディスク構成を分析し、完​​全バックアップのサイズを調べて、圧縮ノードのサイズとストレージの場所（新しいノードまたはオフィスストレージ）を決定します。

• ノード1：200Gb + 400Gb + 200Gb; バックアップサイズ175Gb
• ノード2：200Gb + 500Gb; バックアップサイズ7Gb;

クライアントにアクセスを許可し、ノード2ディスク2がアクティブであるにもかかわらず、使用されていないことを確認するように依頼します。したがって、クラウド内の元のマシンで、ゲストOSを正しく構成し、ProxmoxWebインターフェイスで500GBディスクを無効にする必要があります。この場合、ノード2に関連付けられたままになりますが、「無効」になります。つまり、ノード2はそれを認識しません。



Webインターフェイスでは、GZipのディスクイメージを最大に圧縮して行った変更を使用してバックアップが作成されます。アーカイブには同じ6Gbが含まれていますが、これは実際に予想されています。



オフィススペースにはFTPアクセスのストレージがあり、仮想マシンのアーカイブ画像をアップロードするために1TBが割り当てられているため、このストレージをFTP経由でクラウドOSの「/ bkps」フォルダーに接続することにしました。







受信側サーバーでは、ディスクは次のように構成されています。1TBのLVMデータ1->ストレージデータ1。SSD256Gb上のLVMdata2->ストレージdata2。マシンのイメージをFTPボールに転送した後、上記の方法を使用して、受信サーバーの/ bkpsディレクトリに接続します。受信サーバーのストレージで、「/ bkps」ディレクトリをバックアップストレージとして接続し、Webインターフェイスから以前に作成したノード2に復元してみます。最初の問題：

1. ノード設定は完全にアーカイブにあることが判明したため、コピー＆ペーストを使用してレシーバーで同様の設定を作成する必要はありません。
2. システムでイメージを解凍するには「データ」ストレージが必要であることが判明しましたが、ストレージがないため、解凍プロセスはエラーで停止します。

MCでファイル「2.tar.bz2ノードアーカイブ」を編集しようとして失敗しました。を使用して、仮想化サーバーのコンソールから停止したノード2を試してみます

dd if=/data/vm-101-disk-0 | grep -9cf > /bkps/vm-101-disk-0.img.gz
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

次のコマンドを使用して、FTPにアップロードし、コンソールから「/ dev / data2 / vm-101-disk0」という名前のLVMdata2で作成されたイメージに受信サーバーにデプロイします。

cd /bkps
ls | grep vm101
gunzip -c vm101-disk-0.img.gz | dd of=/dev/data2/vm101-disk-0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

プロセスの最後に、ノード2が正しく起動し、ゲストOSはそれ以上の操作なしで動作を開始しました。



ノード1では、DDを使用してディスク2を400Gbに拡張できなかったため、プロセスはより複雑になりました。その理由はまだ私にはわかりません。時間がなくなると、Solomonは、受信サーバーのストレージの名前を「data1」から「data」に変更し、バックアップからノード1をデプロイすることを決定しました。この構成では、プロセスは正常に実行され、マシンは正常に起動して正常に動作し、接続されているすべてのディスクを確認します。



そして結論として、ストレージ間でサーバー内のディスクを移行することについて簡単に説明します。

1. ノードを停止します。
2. ノード構成設定では、移行が必要なディスクを対象としています。接続されたディスクでのみ機能し、「接続」されていないディスクは移行できないのは不思議です。
3. ターゲットストレージを選択すると、システムはそれを必要なストレージに移動します。

結論に基づいて、このように移動することが可能でした（最も執拗な読者のために移動するボーナス方法）：

1. server-in-the-cloudで、Node1とNode2のドライブの任意のディレクトリへの移行を開始します。
2. FTPにコピーして転送します（トラフィックを減らすために同じgzipで圧縮されている可能性があります）。
3. 圧縮されたイメージを転送した場合は、仮想ディスクファイルをFTPサーバーにデプロイします。
4. 必要なノードに（開始せずに）接続し、「移行」ボタンを押します。

これらの操作により、仮想ディスクイメージが必要なストレージに定期的に移行されます。



ご清聴ありがとうございました。このテキストがお役に立てば幸いです。