Mantıksal Birimi ağ üzerinden doğrudan bir sunucudan diğerine taşıma?

Üzerinde birkaç VM bulunan bir KVM ana makinem var. Her VM, ana bilgisayarda bir Mantıksal Birim kullanır. LV'leri başka bir ana makineye kopyalamam gerekiyor.

Normalde şöyle bir şey kullanırdım:

dd if=/the/logical-volume of=/some/path/machine.dd

LV'yi bir görüntü dosyasına dönüştürmek ve taşımak için SCP'yi kullanmak. Ardından dosyayı yeni ana bilgisayardaki yeni bir LV'ye kopyalamak için DD'yi kullanın.

Bu yöntemin sorunu, VM'nin her iki makinede aldığı alanın iki katı kadar disk alanına ihtiyacınız olmasıdır. yani. 5GB LV, LV için 5GB alan kullanır ve dd kopyası da görüntü için ek 5GB alan kullanır. Bu küçük LV'ler için iyi, ama ya (benim durumum gibi) büyük bir VM için 500GB LV varsa? Bir 500 GB görüntü dosyası dd tutamayacak çok yeni konak makinesi, 1TB sabit disk vardır ve kopyalamak için 500GB mantıksal bir hacme sahip ve ev sahibi OS için oda var ve diğer küçük misafirler için oda.

Ne yapmak istiyorum gibi bir şey:

dd if=/dev/mygroup-mylv of=192.168.1.103/dev/newvgroup-newlv

Başka bir deyişle, verileri doğrudan bir mantıksal birimden diğerine ağ üzerinden kopyalayın ve ara görüntü dosyasını atlayın.

Mümkün mü?

Elbette, bu mümkün.

dd if=/dev/mygroup-mylv | ssh 192.168.1.103 dd of=/dev/newvgroup-newlv

Boom.

Yine de kendinize bir iyilik yapın ve varsayılan blok boyutundan daha büyük bir şey kullanın. Belki de bs = 4M ekleyin (4 MB boyutunda okuma / yazma). Yorumlarda blok boyutları hakkında bazı nitpickler görebilirsiniz; Bu, kendinizi oldukça sık yaptığınız bir şeyse, farklı blok boyutları ile birkaç farklı kez denemek için biraz zaman ayırın ve size en iyi transfer oranlarını neyin elde ettiğini kendiniz görün.

Yorumlardaki sorulardan birini cevaplamak:

Aktarımla ilgili istatistikleri almak için aktarımı pv yoluyla yönlendirebilirsiniz . Sinyal göndermekten elde ettiğiniz çıktıdan çok daha hoş dd.

Tabii ki netcat - veya şifreleme yükünü dayatmayan herhangi bir şey kullanmanın daha verimli olacağını söyleyeceğim, genellikle ek hızın bir miktar kolaylık kaybına uğradığını görüyorum. Gerçekten büyük veri kümelerinde hareket etmediğim sürece, genel olarak rağmen ssh ile yapışıyorum çünkü çoğu durumda her şey zaten Just Work'e ayarlanmış.

Burada, ilerlemeyi gösteren pvve daha büyük parçalar için BS kullanan gzipve ağ trafiğini azaltmak için kullanılan optimize edilmiş bir sürüm var .

Verileri internet sunucuları gibi yavaş bağlantılar arasında taşırken mükemmeldir. Komutu ekran veya tmux oturumu içinde çalıştırmanızı öneririm. Bu şekilde, komutu yürüttüğünüz ana bilgisayara ssh bağlantısı sorunsuz bir şekilde kesilebilir.

$ dd if=/dev/volumegroupname/logicalvolume bs=4096 | pv | gzip | \
    ssh root@78.46.36.22 'gzip -d | dd of=/dev/volumegroupname/logicalvolume  bs=4096'

Bunu yapmak için eski bir freind kullanmaya ne dersiniz? Netcat.

Mantıksal birim türünü kaybeden sistemde

• $ dd if=/dev/[directory]/[volume-name] | nc -l [any high number port]

Sonra alıcı sistemde. tip

• $ nc -w 10 [ip or name] [port] | dd of=/dev/[directory/[volume name]

Çeviri, orgin kutusu dd bu dosyayı ve bu bağlantı noktasını dinleyecek nc (netcat) boru. Alıcı sistemde, netcat, [port] üzerindeki [ip veya ad] 'a kapanmadan önce veri almazsa 10 saniye bekleyecek ve daha sonra bu verileri yazmak için dd'ye aktaracaktır.

İlk olarak lv bir anlık görüntü alacaktı:

lvcreate --snapshot --name my_shot --size <thesize> /dev/<name of vg>/<name of lv>

Bundan sonra, yeni ana bilgisayarda (örneğin lvcreate kullanarak) aynı boyutta yeni bir lv oluşturmanız gerekir. Ardından, verileri doğrudan yeni ana bilgisayara kopyalayabilirsiniz. İşte benim copy komutu örneği:

dd if=/dev/vg0/my_shot bs=4096 | pv | ssh root@some_host -C 'dd of=/dev/vg1/<created lv> bs=4096'

Proxmox pve korumalı VM'yi başka bir ana bilgisayara kopyalamak için prosedürü kullandım. Mantıksal hacim, VM'nin kendisi tarafından tutulan birkaç ilave LV içerir.

Öncelikle mantıksal birimin bağlı olmadığından emin olun. Öyleyse ve "etkin kopya" yapmak istiyorsanız, önce bir anlık görüntü oluşturun ve bunun yerine bunu kullanın: lvcreate --snapshot --name transfer_snap --size 1G

İki 1Gbit bağlı Sunucular arasında çok fazla veri (7 TB) aktarmak zorunda, bu yüzden bunu yapmak için mümkün olan en hızlı yolu gerekli.

SSH kullanmalı mısınız?

Ssh kullanımı, şifrelemesi nedeniyle değil (AES-NI desteğine sahip bir CPU'nuz varsa, çok fazla zarar vermez), ancak ağ arabellekleri nedeniyle söz konusu değildir. Bunlar iyi ölçeklenmiyor. Bir yoktur yamalı Ssh versiyonu adresleri bu sorun, ancak hiçbir hazır paketler olduğu gibi, onun çok uygun değil.

Sıkıştırma Kullanımı

Ham disk görüntülerini aktarırken her zaman sıkıştırma kullanılması önerilir. Ancak, sıkıştırmanın bir darboğaz olmasını istemezsiniz. Gzip gibi çoğu unix sıkıştırma aracı tek iş parçacıklıdır, bu nedenle sıkıştırma bir CPU'yu doyurursa, bir darboğaz olacaktır. Bu nedenle, her zaman sıkıştırma için tüm CPU çekirdeklerini kullanan bir gzip varyantı olan pigz kullanıyorum. Ve bu, GBit hızlarına kadar ve yukarı çıkmak istediğiniz için gereklidir.

Şifrelemeyi Kullanma

Daha önce söylendiği gibi, ssh yavaştır. AES-NI CPU'nuz varsa, bu bir darboğaz olmamalıdır. Yani ssh kullanmak yerine, doğrudan openssl kullanabiliriz.

hızları

Bileşenlerin hız etkisi hakkında bir fikir vermek için, işte benim sonuçlarım. Bunlar iki üretim sistemi arasındaki okuma ve yazma işlemlerinin hafızaya aktarım hızlarıdır. Gerçek sonuçlar ağ hızına, HDD hızına ve kaynak CPU hızına bağlıdır! Bunu en azından büyük bir performans düşüşü olmadığını göstermek için yapıyorum. Simple nc dd: 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s +pigz compression level 1 (speed gain depends on actual data): network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s +pigz compression level 5: network traffic: 2.43GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s +compression level 1 + openssl encryption: network traffic: 2.52GiB 5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s Sonuç: sıkıştırmanın kullanılması, veri boyutunu çok azalttığı için fark edilir bir hızlanma sağlar. Daha düşük ağ hızlarına sahipseniz, bu daha da önemlidir. Sıkıştırma kullanırken, cpu kullanımınızı izleyin. kullanım maksimize edilirse, onsuz deneyebilirsiniz. Sıkıştırmayı AES-NI sistemleri üzerinde sadece küçük bir etki olarak kullanmak, sadece sıkıştırmadan% 30-40 cpu çaldığı için imho.

Ekranı Kullanma

Benim gibi çok fazla veri aktarıyorsanız, ssh istemcinizin ağ bağlantısının kesilmesi tarafından kesilmesini istemezsiniz, bu nedenle her iki taraftaki ekranla başlatmanız daha iyi olur. Bu sadece bir not, burada bir ekran öğretici yazmayacağım.

Kopyalayalım

Bazı bağımlılıklar yükleyin (kaynak ve hedefe): apt install pigz pv netcat-openbsd

sonra hedefte kaynakla aynı boyutta bir birim oluşturun. Emin değilseniz, boyutu almak ve hedef oluşturmak için kaynakta lvdisplay kullanın yani: lvcreate -n lvname vgname -L 50G

sonra, verileri almak için hedefi hazırlayın:

nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname

ve hazır olduğunda, Kaynak üzerinde aktarımı başlatın:

pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1

Not: Verileri yerel olarak aktarıyorsanız veya şifreleme ile ilgilenmiyorsanız, Açar parçasını her iki taraftan da çıkarmanız yeterlidir. Eğer ilgileniyorsanız, asdkjn2hb Şifreleme anahtarıdır, değiştirmeniz gerekir.

Yanıtların geri kalanı iyi çalışmaz ve soru gereksinimlerini karşılamaz, çünkü hedef sunucuda mantıksal birim oluşturmaz, bunun yerine kök diskte / dev / mygroup / myvol altında bir dosya oluşturur. kopyalanan birimin LV araçlarında görünmemesine neden olur lvdisplay.

Tüm süreci otomatikleştiren bir bash betiği oluşturdum: https://github.com/daniol/lvm-ssh-transfer