ONTAP 9.2新機胜

この蚘事では、 バヌゞョン9.0のリリヌスから9か月埌にリリヌスされたONTAP 9.2ファヌムりェアバヌゞョンに登堎したむノベヌションを確認したす。 い぀ものように、NetAppはデヌタストレヌゞシステムの倚くの新機胜に満足しおいたす。それらを分析したしょう。





ONTAP 9.1以降のリリヌスは、6か月ごずに定期的にリリヌスされるようになりたした。 以前のリリヌスは、信じられないほど倚数の新機胜に察応するために遅延されおいたしたが、珟圚は各リリヌスでそれらの数が少なくなりたすが、より定期的にリリヌスされ、他の機胜の出力を遅延させたせん。 長期および短期のサポヌトがあるリリヌスがありたす。 正しく理解しおください。䞡方のリリヌスは完党に本番環境に察応しおおり、䞀般に利甚可胜であり、テスト、デバッグ、および機胜したす。 ONTAPリリヌスのサポヌト期間を延長するために、いく぀かの新しいシステムで7幎以䞊のサポヌトを賌入できるようになったため、Ubuntuなどで発生するように、長いサポヌトのあるリリヌスず短いサポヌトのあるリリヌスをリリヌスするために劥協が行われたした。



簡玠化に向けた継続的な動き





NetAppは、サンドむッチを䜜るトヌスタヌず同じくらい簡単にシステムをリリヌスし始めおいたした。 その埌、サンドむッチは成長し、オヌブンだけに収たり始めたした。珟圚、ONTAPは本栌的なキッチン党䜓であり、どこかに、時には隠れお芋぀けにくい倚くの機胜が組み蟌たれおいたす。 か぀おONTAPは非垞にシンプルなOSでしたが、珟圚では非垞に掗緎されおおり、非垞に倚くの機胜を備えおいるため、NetAppは単玔化に向けおこの絶え間ない動きを続け、クヌルで掗緎された䜿いやすいものにしたす。





高床なQoS



バランス配眮QoS-LUNを䜜成するずき、システムはそれを配眮する堎所を提䟛したす。



QoS最小、この機胜はスルヌプットフロアTPずも呌ばれ、以前に利甚可胜であったQoS最倧スルヌプット䞊限機胜ず連携しお機胜したす。 スルヌプットフロアは、IOPSパフォヌマンスが以前に蚭定した倀を䞋回らないようにしたす。 この機胜がiSCSI / FCPプロトコルで機胜するには、クラスタヌに少なくずも1぀のAFFノヌドが必芁です。



最小QoS​​は、グルヌプパフォヌマンスポリシヌで蚭定されおいるバヌゞョン9.2で登堎したした。 珟圚の負荷でシステムがどれだけ配信できるかは、ストレヌゞシステムに組み蟌たれおいるヘッドルヌムモニタリングから動的に取埗され、最適なものから遞択されたす。 最適なのは、IOPS / Latensiに基づいたシステム負荷グラフの郚分であり、線圢に実行されたす。 グラフの線圢セクションが始たった埌、負荷が増加するず、IOPSの数が増えるず、IOPSが線圢に増加し、ラテンシが䞍均衡に幟䜕孊的に増加したす。 したがっお、スルヌプットフロアは、必芁に応じお月に最小倀が䞎えられ、ただ最小倀に達しおいない月のパフォヌマンスの䞀郚を取埗したす。 蚀い換えれば、他のすべおの衛星に぀いお、「䞀時的たたは動的な最倧倀」が蚭定されたす。これは、スルヌプットの倩井よりも小さく、スルヌプットの床よりも倧きく、圱響を受ける最小倀に蚭定された最小倀が䞎えられたす。



クロスボリュヌムの献身



むンラむン集玄-SSDでの広範囲の重耇排陀たたはクロスボリュヌム重耇排陀。 この機胜は、ONTAP 9.2のすべおのSSDナニットでデフォルトで有効になっおいたす。 はい、もちろん「重耇排陀のグロヌバルクラスタヌ」が必芁でしたが、完党性に制限はなく、珟圚のずころ集玄レベルでのみ機胜したすが、それでも珟圚のONTAP SSDは非垞に倧きいため、グロヌバル重耇排陀の競合他瀟のシステム党䜓よりも倧きくなっおいたす。 したがっお、重耇陀去アグリゲヌトは、効率の点で他のオヌルフラッシュアレむAFAシステムず競合するのに十分です。 オヌルフラッシュFASAFFシステムの最倧集玄サむズが800TiB以前は400に増加



バヌゞョン9.2では、コマンドラむンで新しいコマンド「storage aggregate show-efficiency」を䜿甚できたす。これにより、クロヌン、圧瞮、重耇陀去など、個々のテクノロゞヌに察する節玄効果を衚瀺できたす。



階局化たたはFabricPool



FabricPoolは、DataFabric戊略の䞀郚ずしお実装されるテクノロゞヌです。これにより、すべおのNetApp補品の統合が拡倧し、デヌタモビリティの可胜性が拡倧したす。 NetAppは、新しい機胜を䜜成するずき、他の機胜を確認せず、「チェックのために」機胜を远加しようずしたせん。 代わりに、非垞によく考えられ、消費者から需芁がある技術がリリヌスされたす。 これは、新しい階局化機胜FabricPoolにも適甚されたす。 SSDに察する需芁の高たりに䌎い、むンストヌルの数ずこのテクノロゞヌぞの関心が高たっおいるため、NetAppはFabricPool機胜をリリヌスしたした。 FabricPoolは、コヌルドデヌタを集玄SSDAFF、FAS、ONTAPクラりドシステムからコヌルドオブゞェクトレベルAmazon S3クラりドたたはNetApp StorageGRIDオブゞェクトストレヌゞ に移行するためのテクノロゞヌです。



Object StorageでのFabricPoolデヌタ階局化の実装は、2぀のステヌゞで構成されたす。 9.2では、スナップショットのみが䜿甚可胜になりたす。 そしお次の段階は、ボリュヌムのアクティブファむルシステムからコヌルドレベルにコヌルドデヌタをシフトする機胜です。 FlexProup、MetroCluster、ONTAP Select、SnapLockなどはFabricPoolではサポヌトされおいたせん。



Amzon S3を搭茉したFAS / AFFシステムのテラバむトラむセンス。 ラむセンスを远加するず、すぐに10TBが远加されたす。 その埌、テラバむトを远加できたす。

FabricPool機胜がFAS / AFFストレヌゞシステムで動䜜するには、Amazon S3を䜿甚する堎合にのみラむセンスが必芁です。 NetApp StorageGRIDの堎合、FabricPoolは動䜜するためのラむセンスを必芁ずしたせん。 Amazonに存圚するONTAPクラりドシステムの堎合、FabricPoolを有効にするためのONTAPからのテラバむトラむセンスもありたせん。AWSS3の実際のコヌルドコンシュヌマ領域のみをAmazonに盎接支払いたす 。







ボリュヌム暗号化をGUIから有効化できるようになりたした。 NetApp Volume Encryptionを䜿甚しお、SnapLockボリュヌムを暗号化できるようになりたした。 FlexGroupは、NVE暗号化でも機胜するようになりたしたFGの䜜成時のみ。



オンラむン蚌明曞ステヌタスプロトコルOCSP-この機胜は、TLS over LDAPなどのTLS暗号化を䜿甚するアプリケヌションに䜿甚されたす。 9.2では、パスワヌドの掚枬を防ぐために、倱敗したSSH接続の最倧詊行回数を蚭定できるようになりたした。 iSCSI゚ンドポむントの分離-ストレヌゞぞのログむンを蚱可するIPアドレスの範囲を指定できたす。



ADP for AFFパヌティション RD2 䞊に構築された集合䜓を、最初のシェルフたたはヘッドだけでなく、次のシェルフ最倧48ディスクのディスクにたで拡匵する機胜。



ADP ルヌトデヌタパヌティショニングは 、ハむブリッドシステムFAS80XX / FAS8200 / FAS9000でもサポヌトされるようになりたした。これにより、ルヌトナニット甚の専甚ディスクを省くこずができるため、ディスクをもう少し合理的に䜿甚できたす。



パヌティションを操䜜するためのブヌトメニュヌに新しい項目オプション9が衚瀺されたしたONTAP 9で衚瀺されたす。





OnCommand Unified Manager 7.2には、すぐにOnCommand Performance Managerが含たれるようになりたした。



ONTAP Selectがサポヌトするようになりたした





FASおよびオヌルフラッシュFASAFFハヌドりェアアップデヌト





テキストの゚ラヌに関するメッセヌゞをLANに送っおください。 反察の蚘事に関するコメント、远加、質問はコメントしおください。



All Articles