Geekly Articles each Day

Linuxでの信頌枈みiSCSIストレヌゞの䜜成、パヌト1

パヌト2

前戯


今日は、VMWare vSphereクラスタヌのニヌズを満たすために、2台のLinuxベヌスのサヌバヌから予算フェむルセヌフiSCSIストレヌゞを䜜成した方法を説明したす。 同様の蚘事 たずえば がありたしたが、私のアプロヌチは倚少異なり、そこで䜿甚されおいる゜リュヌション同じハヌトビヌトずiscsitargetはすでに叀くなっおいたす。

この蚘事は、「カヌネルをパッチしおコンパむルする」ずいうフレヌズを恐れない経隓豊富な管理者を察象ずしおいたすが、䞀郚の郚分はコンパむルせずに単玔化しお省くこずができたすが、自分でどのように曞くかを説明したす。 玠材を膚匵させないために、いく぀かの簡単なこずをスキップしたす。 この蚘事の目的は、すべおを段階的に抂説するのではなく、䞀般的な原則を瀺すこずです。

入門


私の芁件は単玔でした。単䞀障害点のない仮想マシン甚のクラスタヌを䜜成したした。 たた、ボヌナスずしお、ストレヌゞはデヌタを暗号化できる必芁があり、サヌバヌをドラッグした敵が圌らに届かないようにしたした。

VSphereは、最も確立された完成品ずしおハむパヌバむザヌずしお遞択され、iSCSIは、FCたたはFCoEスむッチの圢で远加の金融泚入を必芁ずしないため、プロトコルずしお遞択されたした。 オヌプン゜ヌスのSASタヌゲットでは、それは悪くないにしおもかなりき぀いので、このオプションも拒吊されたした。

ストレヌゞは残りたす。 䞻芁ベンダヌのさたざたなブランド゜リュヌションは、自瀟ず同期レプリケヌションのラむセンスの䞡方のコストが高いために砎棄されたした。 したがっお、私たちは自分でそれを行うず同時に、孊習したす。

゜フトりェアが遞択されたずき

その結果、短い苊痛の䞭で、そのような単玔なスキヌムが生たれたした。
画像
各サヌバヌに10ギガビットむンタヌフェヌス2぀の組み蟌みず4぀の远加ネットワヌクカヌドがあるこずを瀺しおいたす。 それらのうち6぀はスむッチスタックに接続されそれぞれ3぀、残りの4぀は隣接サヌバヌに接続されたす。
たた、DRBDを介したレプリケヌションも行われたす。 レプリケヌションカヌドは、必芁に応じお10 Gbpsに眮き換えるこずができたすが、手元に持っおいたので、「それが䜕であるかを盲目にしたした」。

したがっお、いずれかのカヌドが突然死亡しおも、どのサブシステムも完党に機胜しなくなるこずはありたせん。

これらのストレヌゞの䞻なタスクは、倧容量デヌタファむルサヌバヌ、メヌルアヌカむブなどの信頌できるストレヌゞであるため、3.5むンチディスクのサヌバヌを遞択したした。

ビゞネス向け


ディスク

各サヌバヌに8぀のディスクの2぀のRAID10アレむを䜜成したした。
以来RAID6を拒吊するこずを決定 十分なスペヌスがあり、ランダムアクセスタスクでのRAID10のパフォヌマンスが向䞊しおいたす。 さらに、この堎合の再構築時間ず負荷を䞋回るのは1぀のディスクのみであり、アレむ党䜓ではありたせん。

䞀般的に、ここでは誰もが自分で決定したす。

ネットワヌク郚

iSCSIプロトコルでは、ボンディング/むヌサチャネルを䜿甚しお速床を䞊げるこずは意味がありたせん。
理由は簡単です-同時に、ハッシュ関数を䜿甚しおチャネルを介しおパケットを配垃するため、そのようなIP / MACアドレスを遞択しおIP1からIP2ぞのパケットが1぀のチャネルを通過し、IP1からIP3を別のチャネルぞ通過させるこずは非垞に困難です。
ciscoには、パケットがどのEtherchannelむンタヌフェむスを飛行するかを確認できるコマンドもありたす。
# test etherchannel load-balance interface port-channel 1 ip 10.1.1.1 10.1.1.2 Would select Gi2/1/4 of Po1

したがっお、ここでは、構成するLUNぞの耇数のパスを䜿甚するこずをお勧めしたす。

スむッチで、6぀のVLANサヌバヌの倖郚むンタヌフェむスごずに1぀を䜜成したした。
 stack-3750x# sh vlan | i iSCSI 24 iSCSI_VLAN_1 active 25 iSCSI_VLAN_2 active 26 iSCSI_VLAN_3 active 27 iSCSI_VLAN_4 active 28 iSCSI_VLAN_5 active 29 iSCSI_VLAN_6 active

むンタヌフェむスは汎甚性のためにトランキングされおおり、他の䜕かは埌で芋られたす
 interface GigabitEthernet1/0/11 description VMSTOR1-1 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate flowcontrol receive desired spanning-tree portfast trunk end

サヌバヌの負荷を枛らすには、スむッチのMTUを最倧に蚭定する必芁がありたすより倚くのパケット-> 1秒あたりのパケット数が少ない->䞭断が少ない。 私の堎合、これは9198です。
 (config)# system mtu jumbo 9198

ESXiは9000を超えるMTUをサポヌトしおいないため、ただマヌゞンがありたす。

各VLANにはアドレススペヌスが割り圓おられたした。簡単にするために、10.1のようにしたす。 VLAN_ID .0 / 24たずえば、10.1.24.0 / 24。 アドレスが䞍足しおいる堎合、より小さなサブネット内に維持できたすが、より䟿利です。

各LUNは個別のiSCSIタヌゲットで衚されるため、各共通タヌゲットは「共通」クラスタアドレスで遞択され、珟圚このタヌゲットにサヌビスを提䟛しおいるノヌドで発生したす10.1。 VLAN_ID .10および10.1 VLAN_ID .20

たた、サヌバヌには管理甚の氞続アドレスがありたすが、私の堎合は10.1.0.100/24および.200別個のVLAN内です。

゜フトりェア


そのため、ここでは䞡方のサヌバヌに最小限の圢匏でDebianをむンストヌルしたすが、これに぀いおは詳しく説明したせん。

パッケヌゞアセンブリ

コンパむラず゜ヌスでサヌバヌが乱雑にならないように、別の仮想マシンでアセンブリを行いたした。
Debianでカヌネルをビルドするには、ビルドに䞍可欠なメタパッケヌゞを眮くだけで十分です。おそらく、他の䜕かを正確に芚えおいたせん。

kernel.orgから最新のカヌネル3.10をダりンロヌドしお解凍したす。
 # cd /usr/src/ # wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.27.tar.xz # tar xJf linux-3.10.27.tar.xz

次に、安定したSCSTブランチの最新リビゞョンをSVNからダりンロヌドし、カヌネルバヌゞョンのパッチを生成しお適甚したす。
 # svn checkout svn://svn.code.sf.net/p/scst/svn/branches/2.2.x scst-svn # cd scst-svn # scripts/generate-kernel-patch 3.10.27 > ../scst.patch # cd linux-3.10.27 # patch -Np1 -i ../scst.patch

iscsi-scstdデヌモンをビルドしたす。
 # cd scst-svn/iscsi-scst/usr # make

結果のiscsi-scstdは、サヌバヌに配眮する必芁がありたす䟋 / opt / scst

次に、サヌバヌのカヌネルを構成したす。
暗号化をオンにしたす必芁な堎合。

SCSTおよびDRBDにこれらのオプションを含めるこずを忘れないでください。
 CONFIG_CONNECTOR=y CONFIG_SCST=y CONFIG_SCST_DISK=y CONFIG_SCST_VDISK=y CONFIG_SCST_ISCSI=y CONFIG_SCST_LOCAL=y

これを.debパッケヌゞの圢匏で収集したすこのためには、fakeroot、kernel-package、debhelperを同時にむンストヌルする必芁がありたす。
 # fakeroot make-kpkg clean prepare # fakeroot make-kpkg --us --uc --stem=kernel-scst --revision=1 kernel_image

出力でkernel-scst-image-3.10.27_1_amd64.debパッケヌゞを取埗したす

次に、DRBDのパッケヌゞを収集したす。
 # wget http://oss.linbit.com/drbd/8.4/drbd-8.4.4.tar.gz # tar xzf drbd-8.4.4.tar.gz # cd drbd-8.4.4 # dh_make --native --single    Enter

debian / rulesファむルを次の状態に倉曎したすそこには暙準ファむルがありたすが、カヌネルモゞュヌルは収集したせん。
 #!/usr/bin/make -f #     export KDIR="/usr/src/linux-3.10.27" override_dh_installdocs: <  ,     > override_dh_installchangelogs: <  > override_dh_auto_configure: ./configure \ --prefix=/usr \ --localstatedir=/var \ --sysconfdir=/etc \ --with-pacemaker \ --with-utils \ --with-km \ --with-udev \ --with-distro=debian \ --without-xen \ --without-heartbeat \ --without-legacy_utils \ --without-rgmanager \ --without-bashcompletion %: dh $@

Makefile.inファむルでは、SUBDIRS倉数を修正し、その倉数からドキュメントを削陀したす 。そうしないず、パッケヌゞはドキュメントの呪いず共に収集されたせん。

収集するもの
 # dpkg-buildpackage -us -uc -b

パッケヌゞdrbd_8.4.4_amd64.debを取埗したす

それだけです。他のものを収集する必芁はなく、䞡方のパッケヌゞをサヌバヌにコピヌしおむンストヌルする必芁はありたせん。
 # dpkg -i kernel-scst-image-3.10.27_1_amd64.deb # dpkg -i drbd_8.4.4_amd64.deb


サヌバヌ構成

ネットワヌク

むンタヌフェむスは、次のように/etc/udev/rules.d/70-persistent-net.rulesに名前が倉曎されたした。
int1-6はスむッチに移動し、 drbd1-4は隣接サヌバヌに移動したす。

/ etc / network / interfacesは非垞に恐ろしい倖芳をしおおり、悪倢では倢にも思わないでしょう
 auto lo iface lo inet loopback # Interfaces auto int1 iface int1 inet manual up ip link set int1 mtu 9000 up down ip link set int1 down auto int2 iface int2 inet manual up ip link set int2 mtu 9000 up down ip link set int2 down auto int3 iface int3 inet manual up ip link set int3 mtu 9000 up down ip link set int3 down auto int4 iface int4 inet manual up ip link set int4 mtu 9000 up down ip link set int4 down auto int5 iface int5 inet manual up ip link set int5 mtu 9000 up down ip link set int5 down auto int6 iface int6 inet manual up ip link set int6 mtu 9000 up down ip link set int6 down # Management interface auto int1.2 iface int1.2 inet manual up ip link set int1.2 mtu 1500 up down ip link set int1.2 down vlan_raw_device int1 auto int2.2 iface int2.2 inet manual up ip link set int2.2 mtu 1500 up down ip link set int2.2 down vlan_raw_device int2 auto int3.2 iface int3.2 inet manual up ip link set int3.2 mtu 1500 up down ip link set int3.2 down vlan_raw_device int3 auto int4.2 iface int4.2 inet manual up ip link set int4.2 mtu 1500 up down ip link set int4.2 down vlan_raw_device int4 auto int5.2 iface int5.2 inet manual up ip link set int5.2 mtu 1500 up down ip link set int5.2 down vlan_raw_device int5 auto int6.2 iface int6.2 inet manual up ip link set int6.2 mtu 1500 up down ip link set int6.2 down vlan_raw_device int6 auto bond_vlan2 iface bond_vlan2 inet static address 10.1.0.100 netmask 255.255.255.0 gateway 10.1.0.1 slaves int1.2 int2.2 int3.2 int4.2 int5.2 int6.2 bond-mode active-backup bond-primary int1.2 bond-miimon 100 bond-downdelay 200 bond-updelay 200 mtu 1500 # iSCSI auto int1.24 iface int1.24 inet manual up ip link set int1.24 mtu 9000 up down ip link set int1.24 down vlan_raw_device int1 auto int2.25 iface int2.25 inet manual up ip link set int2.25 mtu 9000 up down ip link set int2.25 down vlan_raw_device int2 auto int3.26 iface int3.26 inet manual up ip link set int3.26 mtu 9000 up down ip link set int3.26 down vlan_raw_device int3 auto int4.27 iface int4.27 inet manual up ip link set int4.27 mtu 9000 up down ip link set int4.27 down vlan_raw_device int4 auto int5.28 iface int5.28 inet manual up ip link set int5.28 mtu 9000 up down ip link set int5.28 down vlan_raw_device int5 auto int6.29 iface int6.29 inet manual up ip link set int6.29 mtu 9000 up down ip link set int6.29 down vlan_raw_device int6 # DRBD bonding auto bond_drbd iface bond_drbd inet static address 192.168.123.100 netmask 255.255.255.0 slaves drbd1 drbd2 drbd3 drbd4 bond-mode balance-rr mtu 9216

サヌバヌ管理のフォヌルトトレランスも必芁なため、ミリタリヌトリックを䜿甚したす。 アクティブバックアップモヌドでのボンディングでは、むンタヌフェむス自䜓ではなく、VLANサブむンタヌフェむスを収集したす。 したがっお、少なくずも1぀のむンタヌフェむスが実行されおいる限り、サヌバヌは䜿甚可胜になりたす。 これは冗長ですが、玫斑病はpaではありたせん。 たた、同じむンタヌフェむスをiSCSIトラフィックに自由に䜿甚できたす。

レプリケヌションのために、 bond_drbdむンタヌフェむスがbalance-rrモヌドで䜜成されたした。このモヌドでは、すべおのむンタヌフェむスにパケットが愚かに連続しお送信されたす。 圌は灰色のネットワヌク/ 24からアドレスを割り圓おられたしたが、/ 30たたは/ 31のようにできたす ホストは2぀だけです。

これによりパケットが順番通りに到着しないこずがあるため、/ etc/sysctl.conf内の異垞なパケットのバッファを増やしたす。 以䞋に、非垞に長い間、ファむル党䜓を瀺したすが、どのオプションに぀いお説明したせんか。 必芁に応じお自分で読むこずができたす。
 net.ipv4.tcp_reordering = 127 net.core.rmem_max = 33554432 net.core.wmem_max = 33554432 net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.ipv4.tcp_rmem = 131072 524288 33554432 net.ipv4.tcp_wmem = 131072 524288 33554432 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_dsack = 0 net.ipv4.tcp_fin_timeout = 15 net.core.netdev_max_backlog = 300000 vm.min_free_kbytes = 720896

テスト結果によるず、レプリケヌションむンタヌフェむスは3.7 Gb / sを生成したすが、これはたったく問題ありたせん。

マルチコアサヌバヌがあり、ネットワヌクカヌドずRAIDコントロヌラヌがいく぀かのキュヌ間で割り蟌みの凊理を分離できるため、割り蟌みをカヌネルにリンクするスクリプトが䜜成されたした。
 #!/usr/bin/perl -w use strict; use warnings; my $irq = 77; my $ifs = 11; my $queues = 6; my $skip = 1; my @tmpl = ("0", "0", "0", "0", "0", "0"); print "Applying IRQ affinity...\n"; for(my $if = 0; $if < $ifs; $if++) { for(my $q = 0; $q < $queues; $q++, $irq++) { my @tmp = @tmpl; $tmp[$q] = 1; my $mask = join("", @tmp); my $hexmask = bin2hex($mask); #print $irq . " -> " . $hexmask . "\n"; open(OUT, ">/proc/irq/".$irq."/smp_affinity"); print OUT $hexmask."\n"; close(OUT); } $irq += $skip; } sub bin2hex { my ($bin) = @_; return sprintf('%x', oct("0b".scalar(reverse($bin)))); }

ディスク

ディスクを゚クスポヌトする前に、それらを暗号化し、すべおの消防士のマスタヌキヌを保護したす。
 # cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 --hash sha256 /dev/sdb # cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 --hash sha256 /dev/sdc # cryptsetup luksHeaderBackup /dev/sdb --header-backup-file /root/header_sdb.bin # cryptsetup luksHeaderBackup /dev/sdc --header-backup-file /root/header_sdc.bin

パスワヌドは頭蓋骚の内偎に曞き蟌たれ、決しお忘れられないようにし、キヌのバックアップは地獄に隠されるべきです。
マスタヌキヌのバックアップセクションのパスワヌドを倉曎した埌、叀いパスワヌドを埩号化できるこずに泚意しおください。

次に、埩号化を簡玠化するためのスクリプトが䜜成されたした。
 #!/usr/bin/perl -w use strict; use warnings; use IO::Prompt; my %crypto_map = ( '1bd1f798-d105-4150-841b-f2751f419efc' => 'VM_STORAGE_1', 'd7fcdb2b-88fd-4d19-89f3-5bdf3ddcc456' => 'VM_STORAGE_2' ); my $i = 0; my $passwd = prompt('Password: ', '-echo' => '*'); foreach my $dev (sort(keys(%crypto_map))) { $i++; if(-e '/dev/mapper/'.$crypto_map{$dev}) { print "Mapping '".$crypto_map{$dev}."' already exists, skipping\n"; next; } my $ret = system('echo "'.$passwd.'" | /usr/sbin/cryptsetup luksOpen /dev/disk/by-uuid/'.$dev.' '.$crypto_map{$dev}); if($ret == 0) { print $i . ' Crypto mapping '.$dev.' => '.$crypto_map{$dev}.' added successfully' . "\n"; } else { print $i . ' Failed to add mapping '.$dev.' => '.$crypto_map{$dev} . "\n"; exit(1); } }

スクリプトは、ディスクのUUIDを䜿甚しお、 / dev / sd *にバむンドせずに、システム内のディスクを垞に䞀意に識別したす。

暗号化速床はプロセッサの呚波数ずコアの数に䟝存し、蚘録は読み取りよりも䞊列化されたす。 次の簡単な方法で、サヌバヌが暗号化する速床を確認できたす。
   ,       ,     # echo "0 268435456 zero" | dmsetup create zerodisk        # cryptsetup --cipher aes-cbc-essiv:sha256 --hash sha256 create zerocrypt /dev/mapper/zerodisk Enter passphrase: < >  : # dd if=/dev/zero of=/dev/mapper/zerocrypt bs=1M count=16384 16384+0 records in 16384+0 records out 17179869184 bytes (17 GB) copied, 38.3414 s, 448 MB/s # dd of=/dev/null if=/dev/mapper/zerocrypt bs=1M count=16384 16384+0 records in 16384+0 records out 17179869184 bytes (17 GB) copied, 74.5436 s, 230 MB/s

ご芧のずおり、速床はそれほど熱くありたせんが、実際にはほずんど達成されたせん。 通垞、ランダムアクセスが優先されたす。

比范のため、 Haswellコアの新しいXeon E3-1270 v3での同じテストの結果
 # dd if=/dev/zero of=/dev/mapper/zerocrypt bs=1M count=16384 16384+0 records in 16384+0 records out 17179869184 bytes (17 GB) copied, 11.183 s, 1.5 GB/s # dd of=/dev/null if=/dev/mapper/zerocrypt bs=1M count=16384 16384+0 records in 16384+0 records out 17179869184 bytes (17 GB) copied, 19.4902 s, 881 MB/s

さお、ここではもっず楜しいです。 頻床は明らかに決定的な芁因です。
たた、AES-NIを無効にするず、数倍遅くなりたす。

DRBD

レプリケヌションを構成したす。䞡端からの構成は100同䞀でなければなりたせん。

/etc/drbd.d/global_common.conf
 global { usage-count no; } common { protocol B; handlers { } startup { wfc-timeout 10; } disk { c-plan-ahead 0; al-extents 6433; resync-rate 400M; disk-barrier no; disk-flushes no; disk-drain yes; } net { sndbuf-size 1024k; rcvbuf-size 1024k; max-buffers 8192; # x PAGE_SIZE max-epoch-size 8192; # x PAGE_SIZE unplug-watermark 8192; timeout 100; ping-int 15; ping-timeout 60; # x 0.1sec connect-int 15; timeout 50; # x 0.1sec verify-alg sha1; csums-alg sha1; data-integrity-alg crc32c; cram-hmac-alg sha1; shared-secret "ultrasuperdupermegatopsecretpassword"; use-rle; } }

ここで最も興味深いパラメヌタヌはプロトコルです。それらを比范しおください。

ブロックが蚘録された堎合、蚘録は成功したず芋なされたす...

最も遅い読み取り-高遅延ず同時に信頌できるのはCであり、私は䞭間地点を遞択したした。

次は、DRBDずその耇補に関係するノヌドが動䜜するリ゜ヌスの定矩です。

/etc/drbd.d/VM_STORAGE_1.res
 resource VM_STORAGE_1 { device /dev/drbd0; disk /dev/mapper/VM_STORAGE_1; meta-disk internal; on vmstor1 { address 192.168.123.100:7801; } on vmstor2 { address 192.168.123.200:7801; } }

/etc/drbd.d/VM_STORAGE_2.res
 resource VM_STORAGE_2 { device /dev/drbd1; disk /dev/mapper/VM_STORAGE_2; meta-disk internal; on vmstor1 { address 192.168.123.100:7802; } on vmstor2 { address 192.168.123.200:7802; } }

各リ゜ヌスには独自のポヌトがありたす。

次に、DRBDリ゜ヌスメタデヌタを初期化しおアクティブにしたす。これは各サヌバヌで実行する必芁がありたす。
 # drbdadm create-md VM_STORAGE_1 # drbdadm create-md VM_STORAGE_2 # drbdadm up VM_STORAGE_1 # drbdadm up VM_STORAGE_2

次に、1぀のサヌバヌリ゜ヌスごずに1぀持぀こずができたすを遞択し、それがメむンサヌバヌであり、プラむマリ同期がそのサヌバヌから別のサヌバヌに移動するこずを決定する必芁がありたす。
 # drbdadm primary --force VM_STORAGE_1 # drbdadm primary --force VM_STORAGE_2

すべお、行こう、同期が始たった。
アレむのサむズずネットワヌク速床に応じお、長時間たたは非垞に長い時間がかかりたす。

その進行はwatch -n0.1 cat / proc / drbdコマンドで芳察でき、非垞に穏やかで哲孊的です。
原則ずしお、デバむスはすでに同期プロセスで䜿甚できたすが、リラックスするこずをお勧めしたす:)

最初の郚分の終わり


䞀枚に぀いおは、それで十分だず思いたす。 そしお、非垞に倚くの情報がすでに吞収されおいたす。

第2郚では、この共有で動䜜するようにESXiクラスタヌマネヌゞャヌずホストを構成する方法に぀いお説明したす。

Source: https://habr.com/ru/post/J209460/

More articles:


All Articles