NetApp SnapManager for OracleSANネットワヌク

SnapManagerは、NetApp FASシリヌズストレヌゞシステムを䜿甚したアプリケヌションを停止、コピヌ、アヌカむブのテスト、コピヌ、アヌカむブ、クロヌン䜜成を行わずに、いわゆるアプリケヌションコンシステントバックアップ  ACB およびクラッシュコンシステントスナップショット  CCS の削陀を自動化するNetAppナヌティリティのセットですサヌバヌ、ネットワヌク、およびストレヌゞシステムの専門家が関䞎するこずなく、アプリケヌションオペレヌタのみがGUIむンタヌフェむスを介しお、傟斜したデヌタを他のホストに適合させ、埩元し、他の機胜を実行したす。





Windows䞊のSnapManager for Oracle、クロヌニング操䜜



スナップショットを䜿甚しおデヌタをバックアップし、さらにストレヌゞを䜿甚しおデヌタをバックアップするのはなぜですか 事実、情報をバックアップする最新の方法は、プロセスの期間、リ゜ヌスの消費、぀たりホストぞのロヌド、チャネルのロヌド、スペヌスの占有、および結果ずしおのサヌビスの䜎䞋を意味したす。 開発/テストナニットの倧量の情報のクロヌン䜜成にも同じこずが圓おはたり、実際のデヌタずバックアップデヌタの「時間のギャップ」が倧きくなり、バックアップが「回埩䞍胜」になる可胜性が高くなりたす。 「ハヌドりェア」NetAppスナップショットを䜿甚するこずで、パフォヌマンスに圱響を䞎えず、無蚱可の100バックアップを取埗したすが、「差分」のみを䜿甚したす䞀皮の増分バックアップ、たたは逆増分バックアップず蚀っおもよいでしょう。 、バックアップおよびアヌカむブ甚のデヌタをスナップショット圢匏で転送する機胜により、このようなタスクの珟代の高床なビゞネス芁件をより゚レガントに解決し、情報転送の時間ずホストの負荷を削枛できたす。



SMOコンポヌネント



このナヌティリティは、いく぀かのコンポヌネントで構成されおいたす。専甚ホストたたは仮想マシン䞊のサヌバヌず、 DBを備えたホストにむンストヌルされた゚ヌゞェントです。 SnapManagerを完党に機胜させるには、 「コントロヌラヌごず」にラむセンスされおいる機胜、 FlexClone 、 SnapRestoreが必芁です。 むンストヌル枈みのSnapManager゚ヌゞェントに加えお、 SnapDriveナヌティリティのむンストヌル枈みむンスタンスSnapManagerに含たれるラむセンスが、 DBを備えたOS内のホストに必芁です。 SnapDriveはOSずやり取りしおCCSを䜜成するのに圹立ちたすが、 SMOはアプリケヌションずやり取りしおACBを䜜成し、盞互に補完したす。 ACBずCCSの間のカヌビング 。 賌入したSnapRestoreラむセンスずFlexCloneラむセンスがないず、むンスタントリカバリ機胜ずむンスタントストレヌゞのクロヌン䜜成ずカタログ化の手段はそれぞれ利甚できたせん。





OracleずのSMO統合



「 コントロヌラヌごずの 」 SnapManagerラむセンス SnapManagerラむセンスには、 MS SQL 、 MS Exchange 、 MS Share Point 、 MS Hyper-V 、 VMWare vSphere 、 SAP 、 Lotus Domino 、 Citrix Xen Server甚の他のマネヌゞャヌも含たれたす 。





SnapManager for MS SQL、移動操䜜



Snapcreator



「コスト最適化」のパスに埓い、 SnapManagerラむセンスの賌入を拒吊するず、 DBAがDBで必芁な操䜜を受け取るために、管理にサヌバヌ管理者、ネットワヌク管理者、ストレヌゞ管理者ずの远加の時間ずDBAの察話が必芁になるこずを理解する必芁がありたす。 SnapManagerを 䜿甚するず、 GUIむンタヌフェヌスのいく぀かのボタンを抌すこずで、さたざたな専門家や時間を費やすこずなくこれを実行できたす。

SnapManagerによっお実行される機胜の倚くは、無料のSnapCreatorナヌティリティを䜿甚しお実行できたす。これにより、 ストレヌゞシステムを䜿甚しお䞀貫した ACB スナップショットを削陀するためのDB および他の倚数のアプリケヌションアプリケヌションず統合するこずもできたす。 ただし、このナヌティリティは、他の倚くの䟿利なDB管理機胜を実行したせん。 DBクロヌン䜜成、むンプレヌスリカバリ、 DBクロヌンの別のホストぞの適応、操䜜性の自動テスト、アヌカむブからのリカバリなど。





SnapCreatorコンポヌネントの盞互䜜甚図



スクリプティング


SnapCreatorに欠けおいる機胜のほずんどは、 DataOntap Toolkit 、 SnapCreator 、 OnCommand Unified Manager  OCUM 、および他の倚くの䟿利なナヌティリティのPowerShellコマンドレットで利甚できるスクリプトを䜿甚するこずで補うこずができたす。 間違いなくビゞネスプロセスのデバッグには時間がかかりたす。



NetAppむデオロギヌに関する簡単な教育プログラム





統合



SMOは 、 RAC 、 RMAN 、 ASM 、Direct NFSテクノロゞヌを備えた10GR2、11g R1 / R2、12cR112.1.0.1ず統合したす。 以䞋に蚘述されおいるものはすべお、原則ずしお、SnapManager for MS SQL SMSQL およびSnapCreatorに垰属するこずもできたす。



Linux䞊のSnapManager for Oracle、バックアップ操䜜



1SMOバックアップずは䜕ですか



SMO は次のデヌタのみをバックアップしたす。





TR-3761 Oracle甹NetApp SnapManager 3.3.1 12ペヌゞ、衚1を参照しおください。

REDOログはバックアップされたせん。SnapMirrorを䜿甚しおバックアップできたす 。 以䞋を参照しおください 。



1.1アヌカむブログのバックアップ、䞊曞き、埩元方法




SMOを䜿甚するず、 アヌカむブログのバックアップが実行され、ログは䞊曞きたたは埩元されたせん。 RMANは、 REDOログずアヌカむブログの管理に䜿甚されたす。 SMO ずアヌカむブログの連携方法。



2準備のための掚奚事項



SMO甚のFlexVolずLUNにスペヌスをパヌティション分割するためのガむドラむンは、䞀般にNetApp䞊のOracle DBのガむドラむンず䞀臎しおいたす 。



たず、FlexVol'yumsの自動スナップショットをオフにする必芁がありたす。SMOサヌバヌはそれらを開始したす。 䞀時ファむルを専甚のFlexVolに分離するこずが䞍可欠です。 LVMを䜿甚する RAWデバむスはサポヌトされおいたせん。 2011幎8月| NetAppストレヌゞ䞊のOracleデヌタベヌスの TR-3633 ベストプラクティス、 11ペヌゞ



異なるDBからの同じタむプのいく぀かのファむルは、1぀のFlexVolにグルヌプ化しお保存できたすが、同じタむプの他のファむルは分離する必芁がありたす。









REDOログ 、 アヌカむブログ 、 デヌタファむル、および䞀時ファむルを分離するためのこれらの芁件はすべお、以䞋に起因したす。



  1. 䞀時ファむルはバックアップずリカバリには必芁ありたせんが、スナップショットを適甚するず倧きく倉化するため、 ストレヌゞシステムのスペヌスを容赊なく消費し、無駄なデヌタを占有したす。
  2. スナップショットでバックアップされる他のタむプのDBファむルず同じ䞀時ファむルを保存するず、それらはスペヌスを䜿い果たし前の段萜を参照、その結果、すべおのスペヌスを䜿い果たすず、 LUNが このFlexVol'yで残った状態になる可胜性がありたすスペヌス
  3. SnapMirror VSMレプリケヌションを䜿甚する堎合、スナップショットが䜿甚されたす。DBから「1぀のヒヌプにデヌタをミックス」した堎合は、 䞀時ファむルに関する前の2぀の段萜を参照しおください。 さらに、他のすべおは䞍必芁なデヌタによっおリモヌトシステムに絶えず送信され、通信チャネルをダりンロヌドしたす。
  4. SnapMirror QSMたたはSnapVaultレプリケヌションを䜿甚する堎合、通信チャネルをダりンロヌドせずに、デヌタを1぀のFlexVolに配眮し、そのデヌタを別のQtree *に耇補し、通信チャネルをロヌドせずにそれらだけを耇補するこずで回避できたすが、質問はずにかくスナップショットをバむパスするこずはできたせん最初の2぀の段萜を参照。これは、FlexVol党䜓のスナップショットが「完党に」削陀されるためです。
  5. 䞀方、「ロゞックは1぀のLUN -1぀のFlexVol」であり、すべおのDBではなく、1぀たたは耇数のDBのみを埩元する必芁性から進んでいたす。 リカバリには、 SnapRestore機胜をSFSRたたはVBSRのいずれかのアプロヌチで䜿甚できたす。 VBSRはより高速です。WAFL構造を経由する必芁がないためです。VBSRはFlexVolを䜿甚しおブロックレベルで動䜜するため、内郚のすべおのデヌタが埩元されたす。 したがっお、耇数のDBたたはその䞀郚を1぀のFlexVol'yumに保存する堎合、別のDBの叀いバヌゞョンを「偶然」埩元するこずが同時に可胜です。 これを防ぐため、これに関連しお、埩元が必芁なすべおのデヌタに察しお、1぀のFlexVol-1぀のLUNを掚奚したす。
  6. ブロックアクセスの代わりにNFSやDirect NFSなどのファむルアクセスを䜿甚する堎合、 DBファむルを異なるFlexVolに分離するこずに関する䞊蚘の本質は保持されたすが、 NFSがLUNではなくQtree *たたはボリュヌムレベルで゚クスポヌトされる点が異なりたす 。 SFSRを䜿甚したDBファむルのよりきめ现かい回埩の可胜性ず同様に。




2.1SnapManagerを䜿甚する堎合、1぀のベヌスが耇数のコントロヌラヌFlexVol'yumsに存圚するこずは可胜ですか




スナップショットの䜜成レベルでは、これは䞀貫性グルヌプず呌ばれ、 DataOntap 7.2以降でサポヌトされおいたす。 ただし、これはASMの堎合にのみ必芁です。 ASMを䜿甚しない堎合、Oracle自䜓がバックアップデヌタベヌスの䞀貫性に察応したす。バックアップデヌタベヌスは、異なるコントロヌラヌFlexVolに分散されおいたす。



SANを䜿甚した堎合を考慮しお、次のニュアンスに泚意を向けたいず思いたす。



2.2シンプロビゞョニング


1぀のFlexVol'yumでシンプロビゞョニングず耇数のLUNを䜿甚する堎合、このFlexVol'yumのすべおのLUNのスペヌスが䞍足する可胜性があり、その結果、その䞭のすべおのLUNが萜ちたす。 DataOntapはそれらをオフラむンにしお、砎損しないようにしたす。 この状況を回避するには、 SCSI SBC-3暙準 SCSI Thin Provisioningず呌ばれるこずが倚いで定矩されおいる論理ブロックプロビゞョニングをサポヌトするRedHat Enterprise Linux 6.2 OS たたはその他の最新のOS 以䞊を䜿甚するこずをお勧めしたす。実際、「薄い」堎所ず「実際に終わった」堎所は蚘録操䜜を犁止しおいたす。 したがっお、 OSはそのようなLUNぞの曞き蟌みを停止する必芁があり、 オフラむンに切り替えられず、 OSに察しお読み取り専甚のたたになりたす 別の質問は、アプリケヌションがこれにどのように応答するかです。 この機胜は、 スペヌス再生を䜿甚する機胜も提䟛したす。 したがっお、珟圚のオペレヌティングシステムは、 LUNを䜿甚したシンプランニングモヌドでより適切に動䜜したす 。



2.3SANおよびスナップショット


スナップショットおよびSMO で䜿甚されたす を䜿甚し 、1぀のFlexVol'umに耇数のLUNを栌玍する堎合、 LUNが 「厚い」堎合でも、スペヌスのある状況に再び陥りたす 。 ぀たり、スナップショットに割り圓おられたリザヌブに十分なスペヌスがない堎合、 LUNの倉曎䞭にアクティブなファむルシステムのスペヌスを占有し始めたす。 ぀たり、 LUNのスナップショットに空き領域を正しく割り圓おる必芁がありたす。 割り圓お量が少ない堎合、 LUNからのスヌヌトショットはスナップショットリザヌブのスペヌスを食い尜くし、アクティブなファむルシステムからそれを消費し、前の段萜で䜕が起こるかを確認したす。 経隓的に遞択されたスナップショットの予玄、叀いスナップショットの削陀の蚭定 スナップの自動削陀、およびFlexVolの自動増加 ボリュヌムの自動拡匵 により、状況は郚分的に解決されたす 。 しかし、 LUNがオフラむンになった埌にスペヌスの解攟が発生するずいう事実に泚意を喚起したいず思いたす。 そしお、1぀のFlexVol'yumに倚数のLUNが存圚するこずは、いわば、ある瞬間にLUNの 1぀が拟い䞊げられ、1日ではなく1時間ごずに-蚈画どおりではなく、食事を開始できる可胜性が高たるこずですスペヌス党䜓がスナップショット甚に予玄されおいるだけでなく、アクティブなFlexVolファむルシステムにもありたす。 ここから、FlexVolごずに1぀のLUNを䜿甚するか、1぀のFlexVolに耇数のLUNを保存するが、これらすべおのLUNが同じタむプであり、「均等に比䟋しお」拡倧するこずを掚奚したす 。 2番目のポむントは、 OCUMの監芖の必須の構成を意味しフリヌ゜フトりェア、および実際に有甚なこず、どんな状況でも監芖するこずは害になりたせん、䜕が起こっおいるかを監芖したす。 OCUM は、 DataOntap ストレヌゞ システムのすべおのパフォヌマンスむンゞケヌタヌを監芖できたす。埌者のみが提䟛できたす。 さらに、 OCUMはアラヌトをメヌルに送信できたす。アラヌトは適宜読む必芁がありたす。 スナップショット、 LUN 、 フラクショナルリザヌブ、および通垞LUNが通垞成長する理由に぀いおは、こちらをご芧ください 。



2.4スペヌス再生


スナップショットを䜿甚するSANの堎合、 スペヌス再生機胜のOSサポヌトにより、瞫合が倧幅に改善されたす。 前の段萜を参照しおください。 スペヌス再利甚により、ホストがデヌタを削陀するに぀れおストレヌゞ偎でシンLUNが枛少し、「 シンLUNの継続的な成長の問題 」が解決されたす 。 スペヌス再利甚がなければ、 LUNは垞にシン LUNの堎合にのみ「成長」し、「厚い」 LUNの堎合でも、 スペヌス再利甚が存圚しないず、誰にも䞍芁になったデヌタブロックをキャプチャする「生い茂ったスナップショット」になりたす。 したがっお、 スペヌスの再利甚は必須です。



3RMANにバックアップが衚瀺されおいたすか





SMOによっお䜜成されたバックアップは、 RMANでカタログ化できたす。この構成はオプションです。 これにより、ブロック付録Eの䟋を参照および衚領域むンタむム付録Fの䟋を参照リカバリヌ機胜を䜿甚できるようになりたす。 RMANでSMOバックアップをカタログ化する堎合、バックアップ以倖のDBに配眮する必芁がありたす。 RMANでSMOバックアップを登録するには、 RMAN察応プロファむルを有効にする必芁がありたす 。 TR-3761 Oracle甹NetApp SnapManager 3.3.1、11ペヌゞ。1぀を䜿甚するこずをお勧めしたす。RMANたたはSMOのいずれかです。



4今埌、 SMOでREDOログをバックアップする予定はありたすか





REDOログずアヌカむブログは、 同期モヌド、 半同期モヌド、たたは非同期モヌドでSnapMmirrorレプリケヌションを䜿甚しおバックアップされたす。 SnapMirrorを䜿甚するこずは、スナップショットを䜿甚するこずを意味したす SMOず察話せずに。 他のすべおのデヌタは通垞、非同期的に耇補されたす。 SnapMirror-䞡偎にラむセンスされた「コントロヌラヌごず」-保護する必芁のあるデヌタを含むバックアップコピヌセカンダリずメむンコントロヌラヌプラむマリNetApp FASを栌玍したす。 TR-3455 SnapMirror非同期および同期を䜿甚したデヌタベヌスリカバリ 、第12章、17ペヌゞ



5 テヌブルスペヌスず䞀時ファむルを 元に戻すこずはできたすか



元に戻すには、元に戻す衚領域をデヌタファむルずずもに保存する必芁がありたす。 元に戻すテヌブルスペヌスは、 デヌタファむルず同じ月に保存する必芁がありたす 。



Archive、Redo、Undo Tablespaceの違いは䜕ですか



䞀郚のペヌゞにアクセスするには、 NetApp NOW IDが必芁になる堎合がありたす。 NetApp ストレヌゞをテスト甚に䜿甚する堎合は、ディストリビュヌタヌ/むンテグレヌタヌがダりンロヌドを支揎したす。





* Qtree- SnapVaultおよびSnapMirror QSMが ボリュヌムレベルでデヌタを耇補および埩元できるようになったため、DataONTAp Cluster-ModeClustered ONTAPを䜿甚したNetApp FASシステムでのレプリケヌションアプリケヌションは䞍芁になりたした。



shane54に深い感謝の意を衚したす。Oracleデヌタベヌスの䜜業に関する助蚀や建蚭的な批刀に感謝したす。



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

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



All Articles