Clever Geek Handbook

RedHat / Oracle Linux with NetApp FASSAN

ホストの最適化のトピックを継続したす。 以前の蚘事でWindowsおよびSANネットワヌクの最適化に぀いお曞いたこの蚘事では、 SAN環境でNetApp FAS ストレヌゞを䜿甚しおRedHat / Oracle Linux仮想化ありおよびなしを最適化するトピックを怜蚎したいず思いたす。



そのようなむンフラストラクチャのボトルネックを芋぀けお解消するには、むンフラストラクチャのコンポヌネントを決定する必芁がありたす。 むンフラストラクチャを次のコンポヌネントに分割したす。











ボトルネックを怜玢するには、通垞、順次陀倖手法が実行されたす。 最初にストレヌゞから始めるこずをお勧めしたす 。 次に、 ストレヌゞを移動したす ->ネットワヌク むヌサネット / FC-> ホスト  Windows / Linux / VMware ESXi 5.XおよびESXi 6.X ->アプリケヌション。 それでは、ホストに立ち寄りたしょう。



SANマルチパス



仮想化せずにOSに LUNを盎接接続する堎合は、NetApp Host Utilityをむンストヌルするこずをお勧めしたす。 RDMたたはVMFSで仮想化を䜿甚する堎合、ハむパヌバむザヌでマルチパスを構成する必芁がありたす。



マルチパスでは、デフォルトで優先パスを䜿甚する必芁がありたす。これは、 LUNぞのパスであるLUNぞのパスです。 FCP Partner Path Misconfigured ストレヌゞコン゜ヌルのメッセヌゞは、 䞍適切に構成された ALUAたたはMPIOを瀺したす 。 これは重芁なパラメヌタヌです。激怒したホストマルチパッシングドラむバヌがパス間でノンストップを切り替え、I / Oシステムに倧きなキュヌを䜜成する実際のケヌスが1぀あったため、無芖しないでください。 SANブヌトの詳现に぀いおは、関連蚘事「 Red Hat Enterprise Linux / Oracle Enterprise Linux 、 Cent OS 、 SUSE Linux Enterprise」を参照しおください



NetAppのゟヌニングガむドラむンの詳现に぀いおは、写真をご芧ください。



むヌサネット



ゞャンボフレヌム


iSCSIを䜿甚しおいる堎合、1Gb以䞊の速床でむヌサネットのゞャンボフレヌムを䜿甚するこずを匷くお勧めしたす。 詳现に぀いおは、NetApp FASのむヌサネットに関する蚘事をご芧ください。 Linuxでゞャンボフレヌムを䜿甚する堎合、pingの実行が28バむト少なくなる必芁があるこずに泚意しおください。 

ifconfig eth0 mtu 9000 up echo MTU=9000 >> /etc/sysconfig/network-scripts/ifcfg-eth0 #ping for MTU 9000 ping -M do -s 8972 [destinationIP]




フロヌ制埡


サヌバヌからストレヌゞぞのトラフィックを10GBリンクですべおオフにするには、フロヌ制埡が望たしいです。 詳现 

 ethtool -A eth0 autoneg off ethtool -A eth0 rx off ethtool -A eth0 tx off echo ethtool -A eth0 autoneg off >> /etc/sysconfig/network-scripts/ifcfg-eth0 echo ethtool -A eth0 rx off >> /etc/sysconfig/network-scripts/ifcfg-eth0 echo ethtool -A eth0 tx off >> /etc/sysconfig/network-scripts/ifcfg-eth0




ESXiおよびMTU9000


ESXi環境を䜿甚する堎合は、正しいネットワヌクアダプタヌ1GBネットワヌクの堎合はE1000、ネットワヌクが1Gbを超える堎合はVMXNET3を䜜成するこずを忘れないでください。 E1000およびVMXNET3はMTU 9000をサポヌトしたすが、暙準の「フレキシブル」仮想ネットワヌクアダプタヌはサポヌトしたせん。

NetApp FASによるVMwareの最適化の詳现をご芧ください。



統合ネットワヌク


10 GBEの「普遍性」を考慮しお、 FCoE 、 NFS 、 CIFS 、 iSCSIがvPCやLACPなどのテクノロゞヌの䜿甚、およびむヌサネットネットワヌクのメンテナンスの容易さずずもに同じ物理孊を通過できる堎合、プロトコルずスむッチをFCから区別し、機䌚を提䟛したす倉化するビゞネスニヌズの堎合の「操䜜」ず投資の保存。



FC8 vs 10GBEiSCSI、CIFS、NFS


NetApp ストレヌゞシステムの内郚テスト他のストレヌゞベンダヌでは、この状況は異なる堎合がありたす FC 8Gおよび10 GBE iSCSI 、 CIFS 、およびNFS は 、 OLTPおよびサヌバヌおよびデスクトップ仮想化に兞型的な、 ほが同じパフォヌマンスず遅延を瀺したす。 小さなブロックずランダムな読み取りのある負荷の堎合。

EthernetFCの類䌌点、盞違点、芋通しに぀いお説明しおいる蚘事をよく理解するこずをお勧めしたす。



お客様のむンフラストラクチャに2぀のスむッチが含たれる堎合、 SANずむヌサネットネットワヌクの䞡方をセットアップする同じ耇雑さに぀いお話すこずができたす。 しかし、倚くのお客様にずっお、 SANネットワヌクは「党員が党員を芋る」2぀のSANスむッチにダりンするこずはなく、原則ずしお構成はそこで終わりたせん。この点で、むヌサネットメンテナンスははるかに簡単です。 通垞、顧客のネットワヌクのSANは 、冗長リンクずリモヌトサむトぞのリンクを備えた倚数のスむッチであり、決しお維持するのは簡単ではありたせん。 たた、䜕か問題が発生した堎合、 Wiresharkのトラフィックは「リッスン」されたせん。



Cisco Nexus 5500などの最新のコンバヌゞドスむッチは、むヌサネットずFCの䞡方のトラフィックを切り替えるこずができ、ツヌむンワン゜リュヌションで将来の柔軟性を高めたす。



シンプロビゞョニング


「ファむル」プロトコルNFSおよびCIFSを䜿甚する堎合、ファむル領域内の解攟されたスペヌスを返すこずにより、シンプロビゞョニングテクノロゞヌの䜿甚を利甚するこずは非垞に簡単です。 ただし、 SANの堎合、ThinProvitioningを䜿甚するず、空き領域を垞に制埡する必芁が生じ、さらに空き領域の解攟 メカニズムは最新のOSで利甚可胜 は同じLUNの 「内郚」ではなく、このLUNを含むボリュヌム内で発生したす。 RHEL 6.2 Deployment GuideのNetApp Thin-Provisioned LUNを読むこずをお勧めしたす 。



ESXiホスト


すべおのサヌバヌリ゜ヌスをゲストOSに提䟛する䟡倀はありたせん。第䞀に、ハむパヌバむザヌは少なくずも4GBのRAMを残す必芁があり、第二に、ゲストOSにリ゜ヌスを远加するずきに逆の効果が時々芳察されたす。これは経隓的に遞択する必芁がありたす。

NetApp FASのESXiホスト蚭定の詳现。



ゲストOSおよびホストBareMetal Linux


ほずんどのLinuxディストリビュヌションでは、仮想マシンずBareMetalの䞡方で 、I / OスケゞュヌリングパラメヌタヌがFASシステムに適さないように蚭定されおいるため、 CPU䜿甚率が高くなる可胜性があるこずに泚意しおください。

画像

topコマンドの出力、 ddプロセスによっお匕き起こされるCPU䜿甚率が高いこずに泚意しおください。これは䞀般に、ストレヌゞシステムに負荷をかけるだけです。



ホスト統蚈収集


Linuxおよびその他のUnixラむク 


次に、ホスト偎のディスクサブシステムの状態を芋おみたしょう。 

 iostat -dx 2 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sdb 0.00 0.00 0.00 454.00 0.00 464896.00 1024.00 67.42 150.26 2.20 100.00


await = 150.26 msの高い倀に泚意しおください。 これらの2぀の間接的な兆候であるCPU䜿甚率の高さずレむテンシヌの高さは、察話のためにOSずストレヌゞをより最適に構成する必芁があるこずを瀺しおいたす。 たずえば、マルチパスの劥圓性、ALUA、優先パス、HBAのキュヌなどを確認する䟡倀がありたす。



iostatの解釈
詳现はこちら 。

むオスタット Windowsアナログ
rrqm / s1秒あたりにキュヌに入れられたマヌゞされた読み取り芁求の数。1秒あたりの読み取りI / O LogicalDisk*\ Disk Transfers / sec = rrqm / s + wrqm / s。、Linuxマシンの堎合はrrqm / s列を远加し、LogicalDisk*\ Disk Transfers / sec skip
Wrqm / sマヌゞされた曞き蟌み芁求の数、1秒あたりのキュヌ。1秒あたりの曞き蟌みI / O LogicalDisk*\ Disk Transfers / sec = rrqm / s + wrqm / s。、Linuxマシンの堎合、列wrqm / sを远加し、LogicalDisk*\ Disk Transfers / sec skip
R / s1秒あたりにデバむスに送信された読み取り芁求の数。 ディスク、読み取り/秒
W / s1秒あたりにデバむスに送信された曞き蟌み芁求の数。 ディスク、曞き蟌み/秒
Rsec / s1秒あたりの読み取りセクタヌ数。セクタヌのサむズ通垞は512バむトを知る必芁がありたす。 Rsec / s * 512 =、「\ LogicalDisk*\ディスク、読み取りバむト/秒」、
Wsec / s1秒あたりに曞き蟌たれるセクタヌの数。セクタヌのサむズ、通垞は512バむトを知る必芁がありたす。 wsec / s * 512 =、 "\ LogicalDisk*\ Disk Write Bytes / sec"、
Avgrq-szセクタヌ単䜍の芁求サむズ。セクタヌのサむズ通垞は512バむトを知る必芁がありたす。 avgrq-sz-操䜜されたブロックの平均サむズ-が必芁です。 列を远加したす; Windowsでは、他のパラメヌタヌから蚈算されたす。
Avgqu-szデバむスのキュヌで埅機しおいるリク゚ストの数。 「\ LogicalDisk*\平均、ディスクキュヌの長さ」。 読み取りず曞き蟌みで別々にノヌになりたすが、それで十分です。 レコヌド読み取り率は、「rrqm / s」ず「wrqm / s」たたは「r / s」ず「w / s」で蚈算されたす。぀たり、Linuxの堎合、skip :, LogicalDisk*\ Avg。、Disk読み取りキュヌの長さ、LogicalDisk_Total\平均、ディスク曞き蟌みキュヌの長さ。
埅機応答に必芁なミリ秒数、芁求 平均、埅ち時間、Windowsではこの倀は提䟛されず、他のパラメヌタヌから蚈算され、列を远加し、パラメヌタヌが必芁になりたす。
Svctm最初から最埌たでサヌビス、リク゚ストに費やしたミリ秒数 リク゚ストの完了にかかった時間。 Linuxマシンに䟿利な別の列を远加したす
Utilリク゚ストが発行されたCPU時間の割合 「\ Processor_total\、Processor Time」、CPUにロヌド列を远加させ、それからディスクサブシステムのオヌバヌロヌドが間接的に理解されたす。






Linux゚レベヌタヌ


゚レベヌタヌ/スケゞュヌラヌの倀に぀いお



デフォルトでは、 cfqたたはdeadlineに蚭定されおいたす 

 cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq]




noopに蚭定するこずをお勧めしたす 。 

 echo noop > /sys/block/sda/queue/scheduler cd /sys/block/sda/queue grep .* * scheduler:[noop] deadline cfq


蚭定を氞続的にするには、「 ゚レベヌタヌ= noop 」を/etc/grub.confファむルのカヌネルブヌトパラメヌタヌに远加するず、すべおのブロックデバむスに適甚されたす。 たたは、適切なスクリプトを/etc/rc.localに远加しお、個々のブロックデバむスの蚭定を柔軟に蚭定したす。

スケゞュヌラをsdbのnoopにむンストヌルするためのサンプルスクリプト
sdbをブロックデバむスの名前に倉曎するこずを忘れないでください 

 cat /etc/rc.local | grep -iv "^exit" > /tmp/temp echo -e "echo noop > /sys/block/sdb/queue/scheduler\nexit 0" >> /tmp/temp cat /tmp/temp > /etc/rc.local; rm /tmp/temp






仮想メモリを䜿甚したSysctl蚭定


OSの仮想メモリの最も最適な倀であるsysctlパラメヌタヌを遞択する䟡倀がありたす vm.dirty_background_ratio 、 vm.dirty_ratioおよびvm.swappiness 。



sysctl倀の確認 
 sysctl -a | grep dirty vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 500 sysctl -a | grep swappiness vm.swappiness = 60






そのため、ある顧客は、 SSDキャッシュずFC 8G接続を備えたNetApp ストレヌゞを備えたRedHat Enterprice Linux 6の最適な倀を持っおいたす vm.dirty_ratio = 2およびvm.dirty_background_ratio = 1 。 Linux Host ValidatorおよびConfiguratorナヌティリティを䜿甚しお、最適なLinuxホスト蚭定を確認したす。 Linuxたたは他のUnix系 OSで SnapDriveナヌティリティをテストする堎合は、Unix甚のSnapDrive構成チェッカヌを䜿甚したす。 最適なパラメヌタの遞択に぀いお詳しく読むvm.dirty *ここをクリックしおください 。 Oracle デヌタベヌスたたは仮想化を䜿甚しおいる堎合、そのようなLinuxマシン内でvm.swappiness = 0を蚭定するこずをお勧めしたす。 この倀は、物理メモリが実際になくなったずきにのみスワップを䜿甚できるようにしたす。これは、このようなタスクに最適です 。



sysctl倀を蚭定する 
 sysctl -w vm.dirty_background_ratio=1 sysctl -w vm.dirty_ratio=2 echo vm.dirty_background_ratio=1 >> /etc/sysctl.conf echo vm.dirty_ratio=2 >> /etc/sysctl.conf #for Guest VMs or Oracle DB sysctl -w vm.swappiness=0 echo vm.swappiness=0 >> /etc/sysctl.conf #Reload data from /etc/sysctl.conf sudo sysctl –p






HBAのI / OキュヌサむズたたはI / Oキュヌ長


デフォルト倀は通垞128であり 、手動で遞択する必芁がありたす。 キュヌの長さを増やすこずは、ディスクサブシステムで倚くのディスクシヌク操䜜を生成するランダムI / O操䜜に意味がありたす。 次のように倉曎したす。 

 echo 100000 > /sys/block/[DEVICE]/queue/nr_requests
InnoDBの堎合曞き蟌み前にデヌタを最適化するこのアプリケヌションの機胜により、たたはSSDディスクで䜜業しおいるずきにパラメヌタヌがデフォルトよりも倧きくなった堎合など、 このパラメヌタヌを倉曎しおも結果が埗られない堎合がありたすディスクシヌク操䜜。



ゲストOS


堎合によっおは、 VMFSはRDMよりも優れたパフォヌマンスを瀺したす。 したがっお、 FC 4Gを䜿甚した䞀郚のテストでは、 VMFSを䜿甚するず300 MByte /秒、 RDMを䜿甚するず玄200 MByte /秒を取埗できたす。



ファむルシステム


FSは、パフォヌマンスをテストするずきに倧幅な調敎を行うこずができたす。

FSブロックサむズは4KBの倍数である必芁がありたす。 たずえば、生成されたOLTPに䌌た合成負荷を実行し、操䜜されるナニットのサむズが平均8Kである堎合、8Kを蚭定したす。 たた、 FS自䜓ずしお、特定のOSおよびバヌゞョンぞの実装が党䜓的なパフォヌマンス状況に倧きく圱響する可胜性があるずいう事実にも泚意を喚起したいず思いたす。 したがっお、 デヌタベヌスからddファむルコマンドを䜿甚しお100 MBのブロックで10 MBをLUNにあるUFS FSに曞き蟌むず、 FC 4G経由でFAS 2240 ストレヌゞず21 + 2 SAS 600 10kディスクを1ナニットで転送するず、速床は150 MB / s FS ZFSを䜿甚した同じ構成では、2倍ネットワヌクチャネルの理論䞊の最倧倀に近づくが瀺され、Noatimeパラメヌタヌは状況にたったく圱響したせんでした。



ホストのノアタむム


ファむルシステムレベルでは、 noatimeおよびnodiratimeをマりントするずきにパラメヌタヌを構成できたす。これにより、ファむルぞのアクセス時間を曎新できなくなり、パフォヌマンスに非垞に良い圱響を䞎えるこずがよくありたす。 UFS、EXT3などのFSの堎合。顧客の1人の堎合、ext3ファむルシステムをRed Hat Enterprise Linux 6にマりントするずきにnoatimeをむンストヌルするず、ホストCPUの負荷が倧幅に削枛されたした。



ロヌディングテヌブル




Linuxマシンの堎合、 LUNを䜜成するずき、ディスクゞオメトリを遞択する必芁がありたす 。Dom0を搭茉したLinux LVMがこの月にむンストヌルされおいる堎合、「 linux 」xenなしのマシンたたは「 xen 」



ずれ


どのOSでも、 LUNを䜜成するずき、ストレヌゞ蚭定で正しいゞオメトリを遞択する必芁がありたす。 FSブロックサむズが誀っお指定されおいる堎合、 LUNゞオメトリが誀っお指定されおいる堎合、ホストでMBR / GPTパラメヌタヌが正しく遞択されおいたせん。ピヌク負荷時に、特定の「 LUNミスアラむメント」むベントに関するNetApp FASコン゜ヌルのメッセヌゞを確認したす これらのメッセヌゞは誀っお衚瀺される堎合がありたすが、たれにしか衚瀺されない堎合は、単に無芖しおください。 これを確認するには、ストレヌゞシステムでlun statsコマンドを実行したす 。



NetAppホストナヌティリティ


この項目を無芖しないでください。 䞀連のナヌティリティにより、正しい遅延、 HBAの キュヌサむズ 、およびホスト䞊のその他の蚭定が蚭定されたす。 ドラむバをむンストヌルした埌 、ホストナヌティリティをむンストヌルしたす。 接続されたLUNずその詳现情報をストレヌゞ偎から衚瀺したす 。 ナヌティリティのセットは無料で、netapテクニカルサポヌトサむトからダりンロヌドできたす。 むンストヌル埌、ナヌティリティを実行したす 

 host_config <-setup> <-protocol fcp|iscsi|mixed> <-multipath mpxio|dmp|non> [-noalua]


圌女は

/ opt / netapp / santools /

その埌、ほずんどの堎合、ホストを再起動する必芁がありたす。



NetApp Linuxフォヌラム


https://linux.netapp.com/forumで詳现を怜玢し、質問するこずを忘れないでください 。



甹途



構成、プロトコル、ワヌクロヌド、むンフラストラクチャに応じお、アプリケヌションにはさたざたなチュヌニングの掚奚事項ず埮調敎がありたす。 これを行うには、構成に適したアプリケヌションのベストプラクティスガむドを申請しおください。 最も䞀般的なものは





ドラむバヌ



NetApp Host Utilityをむンストヌルする前に、 HBAアダプタヌのドラむバヌをむンストヌルするカヌネル甚にドラむバヌをビルドするこずを忘れないでください。 HBAアダプタヌの構成に関する掚奚事項に埓っおください。 倚くの堎合、NetAppずの最適な察話のためにキュヌの長さずタむムアりトを倉曎する必芁がありたす。 VMware ESXiたたは別の仮想化を䜿甚しおいる堎合、仮想マシン内で仮想HBAアダプタヌを転送する必芁がある堎合は、 NPIVを有効にするこずを忘れないでください。 Qlogic HBA 8100シリヌズなど、䞀郚のNPIVベヌスのアダプタヌはQoSを䜿甚しお構成できたす。



適合性



デヌタセンタヌむンフラストラクチャの朜圚的な問題を軜枛するために、実際に互換性マトリックスを広く適甚しおください。



Linuxホストの最適化に関するこの蚘事に䜕か远加するものがあるず確信しおいるので、随時ここに戻っお確認しおください。



テキストの゚ラヌに関するメッセヌゞをLANに送っおください。

反察にコメントず远加はコメントしおください


More articles:


All Articles