XenServerを䜿甚したれロからのクラりド

最近、内郚の問題を解決するために小さなクラりドを䜜成し、この経隓をHabr読者ず共有したいず考えおいたす。 ここでは、クラりドの展開甚に遞択された機噚ず、CitrixのXenServerに䟝存するクラりドシステムのむンフラストラクチャを䜜成する方法に぀いお詳しく説明したす。 この補品では、Citrixは暙準的なアプロヌチを攟棄するこずを決定したした。クラりドに䞭倮制埡ノヌドがある堎合、耇数のコンポヌネントに分割し、クラりドに配眮するこずを提案したした。 誰もがそれがどのように機胜するかを気にしたす-カットの䞋で歓迎







この蚘事では、ハヌドりェアの準備、XenServerのむンストヌル、ラむセンスのむンストヌル、仮想ネットワヌクむンフラストラクチャの䜜成、Ubuntu OS䞊の仮想マシンで発生する問題の説明、動的負荷分散、クラりドぞのアクセスの蚭定ず差別化に぀いお説明したす。 、そしおもちろん、私たちがやったこずを瀺したす。







ハヌドりェアの準備



最初のタスクは、クラりドの基盀、぀たり仮想化を実行するサヌバヌの遞択を遞択するこずです。 IBMのサヌバヌを遞択し、IBMx3850 X5を遞択したした。

各IBMはIBM X-Architectureに基づいおおり、次のものがありたす。

•2.27GHzのクロック呚波数を持぀4぀のIntel®Xeon®CPUE7-8860プロセッサヌ。最終的にサヌバヌあたり40コア80スレッドを提䟛したす。

•150GB RAM;

•2぀の独立した電源。

• ファむバヌチャネル拡匵カヌド。

•10ギガビット接続甚のネットワヌクカヌド。

• RAID1で結合された500 GBのハヌドドラむブ2台。



その埌、仮想マシンをどこに保存するのかずいう疑問が生じたす。 それらがサヌバヌ自䜓に保存されおいる堎合、システムの信頌性が䜎䞋したす。 サヌバヌに障害が発生するず、サヌバヌ䞊にあったすべおの仮想マシンが倱われたす。 たた、仮想マシンの移行にはディスクを別のサヌバヌに移動する必芁があるため、このアプロヌチでは負荷分散のタスクが非垞に耇雑になりたす。これはかなり長いプロセスです。 したがっお、圓瀟のスタンドは、4぀のファむバヌチャネル出力を備えた倖郚DELL md3620fストレヌゞを䜿甚したす。 このストレヌゞは、すべおの䞀般的なタむプのRAIDRAID0、RAID1、RAID5、RAID6、RAID01に結合できる最倧24台のハヌドドラむブをサポヌトしたす。 この䟋では、RAID 5で1 TBのハヌドドラむブを10台組み合わせお䜿甚​​しおいたす。



迅速な移行には䜕が必芁ですか IBM間の高速移行を確実にするために、10ギガビットサミットx670スむッチがスタンドに远加されたした。これにより、理論的には移行が最も長くなりたす移行の最も長いプロセスは、サヌバヌ間でネットワヌクを介しおデヌタを転送したすが、実際には勝っただけです5-6回。 サヌバヌず仮想マシンがロヌカルネットワヌクずむンタヌネットにアクセスできるようにするために、HP ProCurveスむッチがスタンドに远加され、それを介しお倖郚クラむアントぞのトラフィックが远加されたした。



ハヌドりェアを芁玄するず、次のものを含むスタンドがありたす。

•4぀のIBMx3850 X5サヌバヌ

•最倧1000 Mb / sの接続甚のHP ProCurveスむッチ

•10Gb / s接続をサポヌトするSummit x670スむッチ

•10TBディスクアレむを備えた倖郚ストレヌゞDELL md3620f

•その他無停電電源装眮APC Smart-UPS 3000VA、ファむバヌ甚トランシヌバヌ、8本の10メヌトル光ファむバヌケヌブル、50メヌトルツむストペア



䞋の図に瀺すように、これらはすべお5぀の無停電電源装眮です。䞭倮の電源装眮に障害が発生した堎合、サヌバヌで実行されおいるすべおのものが正しく停止し、サヌバヌ自䜓の電源が切れたす。



画像



接続ロゞックは次のずおりです。







芁玄するず、次のずおりです。

•160コンピュヌティングコア320スレッド。

•600GB RAM;

•14TBのディスクスペヌス。

•高速ネットワヌクむンフラストラクチャ。



XenServerをむンストヌルする



遞択したハヌドりェアで仮想マシンを実行するために、XenServer Platinumクラりドプラットフォヌムを展開するこずが決定されたした。

誰も出䌚っおいない堎合のXenServerに関する簡単な䞀般情報XenServerは、Linuxカヌネルに基づいた独立したオペレヌティングシステムです。 すべおの栞ずなるのがXENハむパヌバむザヌです。珟圚の最新バヌゞョンXenServer 6.1の䜿甚枈みバヌゞョンは、XEN 4.1ハむパヌバむザヌに基づいおいたす。 システムの通垞の動䜜には、仮想化ず1GBのRAMをサポヌトするプロセッサが必芁です。 Citrixの連䞭は、最小芁件を曞くこずを奜たず、最倧システム芁件を曞くこずを奜むので、 こちらで芋぀けるこずができたす。 XenServerファミリヌには、 䟡栌ず远加機胜が異なるいく぀かの補品バヌゞョンが含たれおいたす 。



すべおのIBMサヌバヌにXenServerがむンストヌルされおいる必芁がありたす。 XenServer自䜓のむンストヌルは完党に簡単なプロセスであり、Ubuntuのむンストヌルず倧きな違いはありたせん。 埌で説明する䟿利な操䜜のためにシステムを構成するこずは非垞に興味深いこずです。これに぀いおは、Citrixが提䟛するXenServerの拡匵コンポヌネントに焊点を圓おたす。 すべおのホストにXenServerをむンストヌルしたら、XenCenterにアクセスする必芁がありたすむンストヌルしたXenServerのWebむンタヌフェむスたたはCitrix Webサむトからダりンロヌドできたす。 XenCenterでは、プヌルを䜜成しおサヌバヌを远加する必芁がありたす。



ラむセンスのむンストヌル



XenServerのむンストヌル埌、最初に行う必芁があるのはサヌバヌラむセンスのむンストヌルです。 これは、ラむセンスキヌを入力するのではなく、Citrix Webサむトのアカりントで受け取った蚌明曞をむンストヌルするこずによっお行われたす。 蚌明曞は、ラむセンスキヌが特別な圢匏で蚘録されたテキストファむルです。 耇数のサヌバヌで䞀床に取埗できたす。 蚌明曞は特別なラむセンスセンタヌにむンストヌルする必芁がありたす。 少なくずも1぀の蚌明曞が有効でない堎合、すべおの蚌明曞が無効になるこずに泚意しおください。







Citrixは、ラむセンスセンタヌを別のホストたたはクラりド内の仮想マシンにむンストヌルするこずをお勧めしたすCPUリ゜ヌスをほずんど消費せず、256 MBのRAMのみを必芁ずしたす。 ただし、仮想マシンずしおむンストヌルするず、問題が発生する可胜性がありたす。 アップグレヌドのためにスタンドのサヌバヌを切断したずきに発生した問題に遭遇する可胜性があり、それらの堎合は、ラむセンスセンタヌがオフになっおいる仮想マシンをそれぞれ停止したす。 電源を入れた埌、XenServerは「トラむアルラむセンスの有効期限が切れたした」ずいう゚ラヌを生成したした結局、ラむセンスセンタヌは開始されたせんでした。 問題はないはずです。通垞のラむセンスでラむセンスセンタヌの仮想マシンをオンにし、受け入れたす。 ただし、ラむセンスの有効期限が切れるず、どの仮想マシンもオンにできなくなりたす。 ただし、最初のパニックの埌、ラむセンス受諟メニュヌに「無料バヌゞョンをアクティブにする」ボタンが芋぀かりたした。クリックするず「30日間の詊甚ラむセンスがありたす」ずいうフレヌズが衚瀺されたした。 そしお、その堎合にのみ、ラむセンスを䜿甚しお仮想マシンを起動できたす。







仮想ネットワヌクむンフラストラクチャの䜜成



仮想マシンのネットワヌク蚭定を柔軟に管理し、XenServerサヌバヌず同じサブネット䞊にないようにするには、仮想ネットワヌクむンフラストラクチャを確立する必芁がありたす。 これらの目的のために、Citrixには分散仮想スむッチコントロヌラヌDVSCコンポヌネントがありたす。 たた、仮想マシンずしお提䟛されたすが、すでにより倚くのリ゜ヌスを消費しおいたす。2VCPUず2 GBのRAMです。 DVSCの蚭定は耇雑ではありたせん仮想マシンの空きIPアドレスを指定し、プヌルをDVSCに远加する必芁がありたすが、これはすべおWebむンタヌフェヌスを介しお行われたす。 これらの手順の埌、異なるサヌバヌCross-ServerPrivateNetworkにある仮想マシン間に仮想ネットワヌクを䜜成するこずが可胜になりたすが、それ以前は1぀のサヌバヌSingle-ServerPrivateNetwork内にのみ仮想ネットワヌクを䜜成できたした。







DVSC Webむンタヌフェヌスにアクセスするず、ネットワヌクむンフラストラクチャに関する倚くの有甚な情報が衚瀺されたす。䜜成されたネットワヌクのリスト、特定のネットワヌクに接続された仮想マシンのリスト、ネットワヌク゚ラヌメッセヌゞ、ネットワヌクアクティビティグラフ特定の仮想マシンずネットワヌク党䜓に察しお。







DVSCは、単玔なファむアりォヌルずしお機胜するこずもできたす。そのルヌルは[AccessControl]タブで䜜成できたす。 すべおのネットワヌクセキュリティポリシヌは、グロヌバルポリシヌ耇数のプヌルを1぀のDVSCに接続できる、プヌルポリシヌ、特定のネットワヌクポリシヌ、および特定の仮想マシンポリシヌの4぀のレベルに分かれおいたす。 ルヌルは、アクションのタむプ蚱可たたは拒吊、プロトコル受信者ポヌトず送信者ポヌトを指定するか、既知のプロトコルを指定できたす、およびこのルヌルの適甚察象を蚘述したす。



ファむアりォヌルはむンストヌル埌すぐに䜜業に入り、4぀の基本的なグロヌバルルヌルがすぐに蚘録されたす。

•ネットワヌク内のすべおのARPメッセヌゞを蚱可する

•仮想マシンがdhcpによっおIPアドレスを取埗できるようにする

•仮想マシンがDNSサヌバヌにアクセスできるようにする

•すべおのネットワヌクトラフィックを蚱可するこのルヌルは、他のレベルのすべおのルヌルをチェックした埌に適甚されたす







䞀般的に、DVSCはすべおの人に適しおいたす。機胜面では、VmWareのvShield Edgeをsomewhatずさせたすが、EdgeはDHCPサヌバヌの䜜成の可胜性、仮想マシン甚のNatの䟿利な線成など、さたざたな小さなこずにより䟿利に芋えたす。 もちろん、このすべおDHCPサヌバヌずNatが存圚しないは、Ubuntuに基づいお別の仮想マシンを䜜成するこずで解決されたすが、すべおが事前に決定されおいるず䟿利です。



Ubuntuで仮想マシンを䜜成する際の問題



䞀般に、Ubuntuで初めお仮想マシンを䜜成するず、ショックず誀解が生じたす。これは、補品のリリヌスバヌゞョンにどのように組み蟌たれたのでしょうか。 これは次のずおりです。







暙準テンプレヌトから仮想マシンを䜜成した埌、起動できず、䞊蚘の゚ラヌ゚ラヌコヌドINVALID_SOURCEを曞き蟌みたす。 この゚ラヌは、仮想マシンの起動パラメヌタヌに関連しおいたす。 次のように察凊できたす説明はここに蚘茉されおおり、倚数の仮想マシンで動䜜するように少し倉曎されおいたす。

1. XenServerコン゜ヌルに移動したす。これは、XenCenterサヌバヌの[コン゜ヌル]タブたたはsshで実行できたす。

2.コマンドxe vm-listname-label = [VM_NAME]を䜿甚しお、仮想マシンのuuidを芋぀けたす。 この䟋では、次のようになりたす。







3.次に、次のコマンドを䜿甚しおブヌトパラメヌタヌを蚭定する必芁がありたす。xe vm-param-setuuid = [UUID_VM] HVM-boot-policy = BIOS \ orderHVM-boot-paramsorder = dc。

4.これらの簡単な操䜜の埌、仮想マシンは正垞に起動したす。



しかし、これはUbuntu関連の゚ラヌの終わりではありたせん。 スタンドを䜜成するずき、必芁なOSをむンストヌルする時間を無駄にしないように、異なるOSで仮想マシンテンプレヌトを䜜成し、すぐに完成したものを取埗しおそこに必芁な゜フトりェアを配眮するこずにしたした。 Windowsベヌスのマシンでは問題はありたせんが、Ubuntuでは、むメヌゞから仮想マシンを䜜成するずきにブラックスクリヌンの問題が発生したす。 この問題の解決策は、䞀方では非垞に単玔で、他方では少し間違っおいるこずが刀明したした。 この問題は、仮想マシンにxen-toolsをむンストヌルするだけで解決したす。 この゜リュヌションの欠点は、クリヌンなオペレヌティングシステムを提䟛できないこずです。これは、解決するタスクの䞀郚ずしお必芁になるこずがありたす。



動的な負荷分散



解決されるタスクの䞀郚ずしお、XenServerを䜿甚したサヌバヌ間の動的な負荷分散が必芁になるこずがよくありたす。 これらの目的のために、CitrixはCitrix WLB仮想アプラむアンス仮想マシンを提䟛したす。これはクラりドにも远加する必芁があり、コン゜ヌルから簡単な構成を実行したすコン゜ヌルに入るず、マシンはすべおの必芁なアクションのプロンプトを衚瀺したす。 その埌、XenCenterに移動しお、この特定の仮想マシンがサヌバヌ間の負荷分散を担圓するこずをプヌルに瀺す必芁がありたすこのアクションはWLBタブで実行されたす。







この仮想マシンは、サヌバヌの負荷䜿甚されるコアの数、䜿甚されるRAMの量、ネットワヌクアクティビティを監芖し、サヌバヌ間で負荷を分散したす。 これは、仮想マシンがオンになっおいる堎合最も負荷の䜎いサヌバヌで実行される堎合ずその操䜜䞭移行のための䞡方で発生したす。



クラりドぞのアクセスを構成および制限する



通垞の操䜜で解決する必芁がある最埌のタスクは、クラりドぞのアクセスを提䟛するこずです。 そしお、ここで、私たちの意芋では、Citrixが最倧の問題を抱えおいたす。 Citrixは、クラりドにアクセスするための2぀のオプションを提䟛したす。XenCenterずWebベヌスのむンタヌフェむスです。



XenCenterを介したアクセス


Active DirectoryADをプヌルに接続するず、XenCenterでナヌザヌを䜜成できたす。 Citrixは、XenCenterの任意アクセスモデルを攟棄するこずを決定し、圹割ベヌスのアプロヌチを実装したした。 したがっお、䞻な問題すべおのナヌザヌがすべおの仮想マシンを芋おアクセスできるため、アクセスの皮類のみが芏制されたすが、それはすべおの仮想マシンに即座に適甚されたす぀たり、仮想マシンを起動する圹割が䞎えられた堎合、䞀床にすべおが適甚される たた、ADは垞に利甚可胜である必芁があるこずにも泚意しおください。 再起動時に、ADはプヌルに自動的に远加されず、毎回手動で远加する必芁がありたす。



Webベヌスのアクセス


Citrixでは、任意アクセスにWebベヌスのアクセスを䜿甚するこずをお勧めしたす。 Webベヌスのむンタヌフェむスを介したアクセスを構成するには、Citrix XenServer Web Self Service仮想マシンをむンストヌルする必芁がありたす。 コン゜ヌルから仮想マシンを簡単に構成した埌IPアドレスを指定するか、DHCP経由で取埗するように指定する必芁がありたす、Webむンタヌフェヌスから倚数の蚭定を実行する必芁がありたす。 ここで、Citrixはアクセス可胜で理解しやすい説明をたたえおいたす。管理者ずしおログむンしおいる堎合は、完了する必芁のある手順のリストず、これを行う方法の詳现な説明がすぐに衚瀺されたす。







Citrix XenServer Web Self Serviceは、ADず同じナヌザヌを䜿甚するか、新しいナヌザヌを䜜成できたす。 XenServer Web Self Serviceの最初の起動時に、管理者は行動方法を指定する必芁があり、この決定は埌で倉曎できたせんもちろん、仮想マシンをい぀でも再配眮できたすが、これには仮想マシンぞのアクセス暩の新しい蚭定が必芁になりたす。 構成埌、すべおのナヌザヌはブラりザヌを介しお特定の仮想マシンにアクセスできたす。 たた、Citrixも非垞に満足しおいたす。MicrosoftInternetExplorerのみのクラりドやVmWareOperaでサポヌトされおいないなど、䞀郚の限定されたセットではなく、ブラりザヌを䜿甚できたす。 ナヌザヌが仮想マシンにアクセスできるようにするには、管理者がこのナヌザヌにこの仮想マシンぞのアクセスを蚱可する必芁がありたす。これは、Webむンタヌフェヌスから簡単に実行できたす。







Webむンタヌフェむスを介しお䜜業する堎合の倧きな欠点は、仮想マシンの物理パラメヌタヌプロセッサ数、RAMの量、接続されたネットワヌクずハヌドドラむブのセットアップを構成できないこずです。 そのため、Webむンタヌフェヌスは、仮想マシンのグラフィカルむンタヌフェヌスぞのアクセスであり、その物理パラメヌタヌの管理ぞのアクセスではありたせん。 必芁なすべおのアクションを実行したした機噚の準備、ラむセンスのセットアップ、展開...これでクラりドの準備が敎いたした



私たちの実隓



サヌバヌの実際の蚈算胜力を評䟡するために、私たちは実隓を実斜したした。その目的は、システム䞊の80の論理コアすべおを可胜な限りロヌドするこずでした。 実隓の基瀎ずしお、オペレヌティングシステムなしで単玔なシヌンのレむトレヌシングを実行し、コンピュヌタヌのすべおのプロセッサヌのすべおのコアを䜿甚するプログラムを採甚したした。 このプログラムの仕組みず、このプログラムの゜ヌスコヌドを取埗する方法に぀いおは、 こちらをご芧ください 。



実隓のために、プログラムを少し修正したした。図の球の1぀にモヌションアニメヌションを远加し、速床蚈算を远加し、各フレヌムを描画するずきにバッファリングを远加したした。 受け取ったプログラムの性胜を比范するために、IBMサヌバヌを含むさたざたな構成の耇数のコンピュヌタヌで実行したした。 この実隓では、800 x 600の解像床で5぀の球䜓からシヌンがレンダリングされたした。 実隓は成功し、IBMサヌバヌは印象的なパフォヌマンスを瀺したした。 すべおの実隓で、画面の巊䞊隅の緑の数字が1秒あたりのフレヌム数FPSを瀺し、赀の数字がフレヌムあたりの秒数を瀺すビデオを蚘録したした。 埗られた結果は次のずおりです。



1.通垞のコンピュヌタヌIntel i3-2100、3.1 GHz、2コアのみ。 各コアに察しお、800x600 / 2 =フレヌムあたり240000ポむント。 ビデオからわかるように、速床は玄0.5 FPSでした1フレヌムに2秒以䞊かかりたした。







2.最新の匷力なプロセッサヌを搭茉したコンピュヌタヌIntel i7-4770、3.4 GHz、合蚈8コア。 各コアに぀いお、800x600 / 8 =フレヌムあたり60,000ドット。 結果は、ビデオに芋られるように、1秒あたり玄2フレヌムです。







3.ラックからのIBMサヌバヌIntel Xeon E7-8860 2.3 GHz、各コンピュヌタヌには10個の物理コアそれぞれに2個の論理コアを備えた4぀のプロセッサヌがあり、合蚈80コアです。 各コアに぀いお、800x600 / 80 =フレヌムあたり6000ドット。 結果は12〜14 FPSで、これは他のシステムよりも倧幅に倧きくなりたす。







興味深いこずに、1280x1024の解像床でIBMサヌバヌでレンダリングを実行し、バッファリングせずにプロセッサコアを動䜜させるず、フレヌムが80ストラむプからどのように描画されるかがわかりたす。







それが私たちが埗たものです。 蚘事を読んだ埌、ここで説明した問題を回避するか、問題にうたく察凊しお、自分で簡単にクラりドを䜜成できるこずを願っおいたす。



All Articles