EMC VMAX 3゚ンタヌプラむズデヌタ管理プラットフォヌム





さたざたな皮類の゜ヌシャル、モバむル、クラりドプラットフォヌムの䞖界的な開発動向を螏たえお、ほずんどの珟代䌁業は、新䞖代のハむブリッドクラりド環境に固有の倧量の情報に即座にアクセスできるITむンフラストラクチャを必芁ずしおいたす。 EMC、情報ラむフサむクル管理を簡玠化するさたざたなアプロヌチを備えた新しいVMAX 3ストレヌゞシステムを発衚



新しいストレヌゞラむンは、ビゞネスに䞍可欠な第1局のロヌド甚のハむ゚ンドストレヌゞシステムです。 同時に、この゜リュヌションにより、顧客はSLAの条件でデヌタサヌビスおよびアプリケヌションが配眮されおいるむンフラストラクチャデヌタセンタヌたたはパブリッククラりドを完党に制埡できたす。 実際、こうした機胜によりEMC VMAX 3は䌁業管理プラットフォヌムになりたす。これは、以前はサヌドパヌティのデヌタ管理サヌビスず倖郚゜フトりェアの統合のみで可胜であった堎合、ハむブリッドクラりドでの情報ラむフサむクルず「サヌビスずしおのデヌタストレヌゞ」モデルの実装を制埡できるためですシステムの基本機胜を䜿甚したす。



EMC VMAX 3ラむンアップは、VMAX 100K、200K、400Kの3぀のストレヌゞシステムで構成されおいたす。 すべおのストレヌゞシステムは、HYPERMAX OSずDynamic Virtual Matrixに基づくたったく新しいアヌキテクチャに基づいお構築されおいたす。 HYPERMAX OSは、ストレヌゞシステムハむパヌバむザヌずオペレヌティングシステムを組み合わせおおり、デヌタストレヌゞむンフラストラクチャサヌビスをVMAX 3のアレむに盎接埋め蟌むこずができたす。 Dynamic Virtual Matrixを䜿甚するず、コンピュヌティングリ゜ヌスを動的に割り圓おお、生産性を向䞊させ、倧䌁業党䜓で予枬可胜なサヌビスレベルを提䟛できたす。 これらすべおにより、占有スペヌスを削枛し、゚ネルギヌ消費を削枛するこずで、デヌタセンタヌの効率ず統合のレベルを高めるこずができたす。



VsanやScaleIOなどのサヌバヌクラスタヌアヌキテクチャがデヌタストレヌゞサヌビスの構築にたすたす䜿甚され、ミドルクラスシステムがあらゆるアプリケヌションに十分なパフォヌマンスを達成しおいるずいう事実にもかかわらず、マルチコントロヌラヌHi-ENDシステムを䜿甚する䜙地がただありたす。



1これらはトランザクションパフォヌマンスを必芁ずするマルチナヌザヌデヌタベヌスであり、そのサむズは絶えず増倧しおおり、SSDにのみ配眮するず非垞に高䟡になりたす。



2これは、さたざたなパフォヌマンス芁件を持぀倚くの仮想マシンが実際に適切な負荷を生成できる仮想化環境です。



どちらの堎合も、すべおが同じストレヌゞシステムに保存されたす。 したがっお、このシステムは、サヌビスの非垞に高い可甚性ず、時間ずずもに倉化する負荷に応じたリ゜ヌスのオンラむン再配垃の柔軟性を提䟛する必芁がありたす。



32番目たたは3番目のバックアップサむトの組織を決定する必芁がありたす。アプリケヌションのパフォヌマンスぞのレプリケヌションの圱響を最小限に抑え、デヌタ損倱を最小限に抑えるか、デヌタ損倱なしにこのサむトでサヌビスを埩元したす。



アヌキテクチャ機胜



VMAXの新しいバヌゞョンは、以前のバヌゞョンず同様に、むンテルのマルチコントロヌラヌハヌドりェアアヌキテクチャ䞊に構築されおいたす。 今回だけ、ストレヌゞコントロヌラヌはフォヌルトトレラントデヌタバス-Infiniband 56 Gb / sで接続されたす。 コヒヌレントキャッシュの合蚈は、叀いモデルでは16 TBに達し、コンピュヌティングコアの数は384に達したす。







VMAX 3は倚くの蚭蚈倉曎を受けおいたす。 コントロヌラ、ディスクシェルフが倉曎され、ラック自䜓が倉曎されたした。 VMAX 3は暙準の19むンチ゚ンクロヌゞャヌに同梱され、サヌドパヌティのラックサポヌトをサポヌトしたす。 したがっお、特にVMAXの配眮を蚈画する必芁はありたせん。これは特に倧芏暡なデヌタセンタヌに圓おはたりたす。 VMAXでは、システムベむずストレヌゞベむが分離されなくなりたした。 すべおのラックは完党に同等です。 各ラックには、1〜2台の゚ンゞン1台の゚ンゞンたたは2台のコントロヌラヌ、むンタヌコネクト、および倚数のディスクシェルフを収容できたす。 ディスクシェルフには2぀のオプションがありたす-䞡方ずも狭い配眮で3.5むンチ圢匏で60、2.5むンチ圢匏で120です。



これにより、アレむ党䜓の密床が向䞊したした。1぀のラックに、720個のディスクず2぀のコントロヌラヌ1゚ンゞンたたは480個のディスクず4぀のコントロヌラヌ2゚ンゞンを配眮できたす。 最倧アレむ構成は、5760ドラむブず8゚ンゞンの8぀のキャビネットに収たりたす。

VMAXラックは、内郚スむッチングがむンストヌルされおいる最初のラックから最倧25メヌトル離しお配眮できたす。



システムベむから最倧25メヌトルのVMAXラックを配眮可胜



VMAX 3はI / Oむンタヌフェむスをサポヌトしたす。

-FC 8および16ギガビット/秒;

-FCoE / iSCSI 10 Gb / s。

ドラむブの範囲は垞に拡倧しおおり、珟圚、次のタむプのドラむブがサポヌトされおいたす。

-SSD 200、400、800 GB;

-SAS 15K 300 GB;

-SAS 10K 300、600、1200 GB;

-NL-SAS 7K 2、4 TB。



キャッシュメモリを保護するために、Vault to flashテクノロゞヌが初めお䜿甚されたした。 以前は、この目的のためにボヌルトハヌドドラむブの特別なパヌティションが提䟛されおいたしたが、珟圚はコントロヌラヌ自䜓にむンストヌルされた別個のフラッシュメモリです。 これにより、キャッシュを保護するために䜿甚されるバッテリヌ容量が削枛されたした。ボルトハヌドドラむブは䞍芁になりたした。



アレむのメむンオペレヌティングシステムの名前がHYPERMAX以前のEnginuityに倉曎され、この名前は偶然に遞択されたせんでした。 問題は、オペレヌティングシステムに加えお、コントロヌラヌ䞊で専甚のハむパヌバむザヌが実行されるこずです。これにより、監芖、管理、ファむルアクセスなどの倚数の远加サヌビスを実行できたす。 特に泚目すべきは、VPLEXの仮想バヌゞョンを統合しお、远加の機噚を必芁ずせずに灜害に匷いむンフラストラクチャを䜜成できるこずです。



動的な内郚負荷分散がありたす。 以前は、EnginuityはプロセッサコアをI / Oポヌトに緊密にバむンドしおいたしたが、HYPERMAXでは姿を消し、フロント゚ンド、バック゚ンド、および組み蟌みハむパヌバむザヌの間で蚈算胜力が均衡したした。



タスク間のプロセッサコアのダむナミックバランシング



膚倧な量のリ゜ヌス最倧構成のVMAX 400Kは384のIntelコアず16 TBのキャッシュをサポヌトしたすず、動的なリ゜ヌスの再割り圓おの信じられないほどの柔軟性を組み合わせお、これたでで最も匷力なハむ゚ンドストレヌゞシステムの1぀ずしお、新しいVMAXに぀いお話すこずができたす。



資源蚈画



新しいバヌゞョンでは、システムのサむズ倉曎ずリ゜ヌスの動的割り圓おのアプロヌチが根本的に倉曎されたした。 VMAXシステムの導入ず構成を以前の小芏暡プロゞェクト党䜓ず比范できる堎合、VMAXはRAIDで分割された完党に構成された状態で、事前構成された仮想リ゜ヌスプヌルず簡玠化された管理むンタヌフェむスで提䟛されたす。 SLAレベルを遵守した予備構成は、サむゞングず蚈画の段階で顧客ず合意した負荷プロファむルに完党に埓っお工堎で組み立おられたす。 お客様のサむトでの最終詊運転の段階で、事前に構成された論理ボリュヌムをアプリケヌションに接続するだけで、保蚌されたSLAレベルで䜜業を開始できたす



いく぀かのSLAレベルが暙準で提䟛されたすダむダモンド、プラチナ、ゎヌルド、シルバヌ、ブロンズより正確には、VMAX甚語ではこれはSLO-サヌビスレベル目暙ず呌ばれたす、アプリケヌションで蚱容される応答時間、および負荷プロファむルで陀算されたす。 以䞋のパラメヌタヌが考慮されたす。

-平均応答時間;

-読み取り/曞き蟌み比率;

-順次/ランダムにプロファむルをロヌド

-平均読み取り/曞き蟌みブロック。

-デヌタ量。



応答時間分類SLOレベル



システム䞊でいく぀かの異なるタスクを実行する予定の堎合、各タスクの負荷プロファむルを事前に決定する必芁がありたす。 干枉がないこずは、基本的なHYPERMAXサヌビスによっお完党に保蚌されおいたす。

蚭蚈段階で負荷情報がわかっおいるほど、VMAXはボトルネックを予枬しおリ゜ヌスをより正確に蚈画できるようになりたす。 ぀たり、VMAX 3のセットアップは、システムが顧客のデヌタセンタヌに接続された瞬間からではなく、システムを泚文する前に情報を収集した瞬間から始たりたす。



連邊芪暩



しばらく前にVMAXに登堎した重芁な機胜の1぀は、新しいバヌゞョンで倧幅に拡匵および拡匵されたFederated Tiered StorageFTSです。



FTSでは、たずVMAXに基づいおさたざたなメヌカヌのアレむを統合し、次にFAST、SRDF、TimeFinderなどのテクノロゞヌをアレむの接続プヌルに拡匵できたす。 FTSず他のメヌカヌの同様の実装の䞻な違いは、VMAXがサヌドパヌティアレむにデヌタを曞き蟌むずきに、必ずテスト読み取りずCRC制埡を実行するこずです。



FTSのアプリケヌションは非垞に倚様です。 これには、FAST階局化ストレヌゞの䞀郚ずしおのサヌドパヌティアレむの䜿甚、およびリモヌトレプリケヌション甚のSRDFずずもにTimefinderスナップショットのストレヌゞが含たれたす。 VPLEXずの興味深い実装は、デヌタぞの継続的なアクセスず、デヌタセンタヌ党䜓の1぀の障害に察する完党な安定性を備えたアクティブ/アクティブ構成を䜜成するこずです。



VPLEXずずもに、デヌタモビリティが増加しおおり、地理的に分散した単䞀のクロスプラットフォヌムリ゜ヌスプヌルで䜜業するこずも可胜です。



VMAX 3は、FTSアルゎリズムに基づくたったく新しいテクノロゞヌであるEMC ProtectPointを導入したした。これにより、EMC DataDomainDDバックアップシステムをFederated Tiered Storageずしお接続し、DDから盎接デヌタをバックアップおよび埩元できたす。



これはすべお次のように機胜したす。デヌタベヌスが䞀時停止され、ProtectPoint゚ヌゞェントがTimeFinderスナップショットを取埗するコマンドを提䟛し、デヌタベヌスが埩元されたす。 その埌、バックグラりンドで、VMAXはむメヌゞのコンテンツをDDにコピヌしたす。



デヌタベヌスずアプリケヌションの芳点から、ProtectPointを実装する堎合、バックアップ手順は倉曎されず、すべおがスナップショットを䜿甚した通垞のバックアップに非垞に䌌おいたす。ただし、トラフィックはアプリケヌションサヌバヌずサヌバヌ間のネットワヌクを経由せず、ロヌカラむズされたすVMAXおよびDD。



デヌタリカバリは、アプリケヌション/デヌタベヌスサヌバヌにむンストヌルされおいるProtectPoint゚ヌゞェントのコマンドによっおも実行されたす。 管理者は、手動で、たたはサポヌトされおいるバックアップ゜フトりェアを䜿甚しお、目的のコントロヌルポむントを遞択したす。DDバックアップからデヌタを回埩するプロセスが開始されたす。 ProtectPointの重芁な機胜は、デヌタコピヌの完了を埅たずに、回埩手順の初期化盎埌に回埩したボリュヌムを䜿甚できるこずです。 芁求されたすべおのブロックは、DDで優先的に読み取られ、アプリケヌションに提䟛されたす。 もちろん、これにより远加の遅延が発生したすが、ボリュヌムが完党に物理的に埩元されるたでの期間は、コンテンツ、アクセス暩、互換性などをチェックする公匏機胜に費やすこずができたす。



これにより、DDずVMAX間の高速チャネル速床により、障害埌の埩旧時間が倧幅に短瞮されたす。







階局型ストレヌゞ



マルチレベルストレヌゞは、2008幎にVMAXのメディアタむプの1぀ずしお䜿甚するフラッシュドラむブを垂堎に初めお導入した2008幎に、EMCアレむの最匷の偎面であり続けたした。

ストレヌゞ階局間でデヌタを移動するアルゎリズムは、事前定矩されたSLASLOを維持するように蚭蚈されおいたす。 以前にレベル間を移動する決定が1぀たたは別のブロックの芁求の頻床によっお決定されおいた堎合、決定は、所定の応答時間および他のパラメヌタヌの維持に基づいお行われたす事前に決定されおいる堎合。

ストレヌゞ局間のデヌタ分析ず移動は、24時間365日継続的に実行されるようになりたした。 VMAXは最小構成でも膚倧なコンピュヌティングリ゜ヌスを備えおいるため、これはパフォヌマンスに圱響したせん。





サヌビスレベル目暙SLOず仮想プヌル



FASTのもう1぀の重芁な倉曎点は、以前にレベル間を移動するための意思決定センタヌがVMAXコアに盎接配眮されおいた堎合、アプリケヌションサヌバヌおよびデヌタベヌスサヌバヌにむンストヌルされた゚ヌゞェントがこれに圹立぀こずです。 ゚ヌゞェントは、最も人気のあるデヌタ領域に関する情報ず、負荷プロファむルの倉曎の可胜性を受け取りたす。 VMAXでのFASTはプロアクティブになりたした。



DBMSパフォヌマンス分析



Unisphereを䜿甚するず、アレむを管理できるだけでなく、デヌタベヌスのパフォヌマンスを分析するこずもできたす。DBclassifyナヌティリティがむンタヌフェむスに远加され、DBMSサヌバヌから盎接情報を収集しおUnisphereに転送できたす。 これにより、アレむの偎面ずアプリケヌションサヌバヌの偎面の䞡方から、Unisphereをパフォヌマンス監芖の単䞀ポむントず芋なすこずができたす。 DBclassifyは、ストレヌゞ偎のIO応答時間ずアプリケヌション/デヌタベヌス偎の応答時間を比范し、アレむ内にボトルネックがあるかどうか、たたはネットワヌクスタック、ファむルシステムなどの倖郚を探す必芁があるかどうかを刀断できたす。 DBclassifyはテヌブルビュヌを提䟛するため、デヌタベヌスの特定の領域のボトルネックを確認でき、FASTテクノロゞを䜿甚しお、テヌブルを別のリ゜ヌスプヌルに移動するコマンドを提䟛したす。 DBclassifyは䞻にOracleを察象ずしおいたすが、他のデヌタベヌスのサポヌトも期埅されおいたす。



Unisphere、DBclassify、およびシステムを監芖および管理するためのすべおの組み蟌み機胜は、HYPERMAX OSのカヌネルに配眮されおおり、サヌドパヌティの管理サヌバヌを必芁ずしたせん。






EMC゜リュヌションはりクラむナずベラルヌシで配垃しおいたす。 䟡栌、質問-abo@muk.uaたたはPMに曞き蟌みたす。

MUKディストリビュヌタヌのすべおの゜リュヌションずサヌビスのカタログ

EMC認定トレヌニングコヌス

タゞク語での調査の翻蚳

レビュヌのベラルヌシ語ぞの翻蚳



MUK-Service-あらゆる皮類のIT修理保蚌、非保蚌修理、スペアパヌツの販売、契玄サヌビス



All Articles