james113's Posts

james113's Posts

3の機種の本体DiskのFailに関して、1本目のFailは本体のSpareに切り替わり、2本目のFailは拡張シェルフの Spareに切り替わりが完了している場合でも、3本目のFailが発生した際にはサービス提供不能となりますでしょうか? また、3の機種において、OSが存在するパーティション、セクタは、本体および拡張筐体のスペアの保護対象 となりますでしょうか? また1... See more...
3の機種の本体DiskのFailに関して、1本目のFailは本体のSpareに切り替わり、2本目のFailは拡張シェルフの Spareに切り替わりが完了している場合でも、3本目のFailが発生した際にはサービス提供不能となりますでしょうか? また、3の機種において、OSが存在するパーティション、セクタは、本体および拡張筐体のスペアの保護対象 となりますでしょうか? また1の機種において本体のホットスペアディスクのロケーションは、拡張シェルフと同等に Disk Failにより遷移していきますでしょうか?それともDisk Fail後のDisk交換によりスペアの ロケーションが切戻ることは考えられますでしょうか?
1,2,3それぞれのケースにおいて、それぞれ何本ディスクが同時にFailした際に バックアップ(DataDomainのファイルシステム)のサービス提供が不可能となるか教えていただくことは可能でしょうか?
1に関して、1本がSpareのためデータディスクが3本であるのにRAID6というのは間違いないでしょうか?
DataDomainのsnmpdが再起動したタイミングで下記OIDのSNMP TrapがDataDomainから発砲され Manager側で検知しております。 1.3.6.1.6.3.1.1.5.1 こちらはDataDomainのMIBファイルに存しない、一般トラップでcoldStartを示すものですが、DDOSの 再起動は確認されておりません。DDOSはLinuxベース... See more...
DataDomainのsnmpdが再起動したタイミングで下記OIDのSNMP TrapがDataDomainから発砲され Manager側で検知しております。 1.3.6.1.6.3.1.1.5.1 こちらはDataDomainのMIBファイルに存しない、一般トラップでcoldStartを示すものですが、DDOSの 再起動は確認されておりません。DDOSはLinuxベースと認識しておりますが、DataDomainのMIBリファレンス にも存在しない、一般トラップも発砲される仕様となりますでしょうか? 以上、よろしくお願いいたします。
DDOSがインストールされているロケーションとRAID保護について教えてください。 1. DD860のようにOS Diskが4本(内1本がSpare)で構成されているタイプ 2. DD4500のようにOS DiskがSSD 3本(Spare無し)で構成されているタイプ 3. DD670やDD2500のようにOS Diskの所在が不明なタイプ 上記のパターンがあると認識して... See more...
DDOSがインストールされているロケーションとRAID保護について教えてください。 1. DD860のようにOS Diskが4本(内1本がSpare)で構成されているタイプ 2. DD4500のようにOS DiskがSSD 3本(Spare無し)で構成されているタイプ 3. DD670やDD2500のようにOS Diskの所在が不明なタイプ 上記のパターンがあると認識しておりますが、それぞれについて下記を知りたいと 考えております。 ・ RAID保護レベル ・ OS Disk故障時にSpareがキックされるかどうか ・ 物理ロケーション 以上、よろしくお願いいたします。
帯域をフルで使用している時間帯はgcomp値が50倍に対して、帯域を使用しない時間帯はgcompが300倍を超えています。 重複排除/圧縮が効いてはいてもバックアップデータのサイズが大きければ帯域をフルで使用するものと思っていましたが 実際には1/10しか使用していません。御社サポートセンターにも確認してみようかと思います。
DataDomainにてDDBoostを使用し、NBUにて2台のDataDomain間のManaged File Replicationを実行している 環境がございます。当環境においてバックアップのソースファイルによって、WAN帯域をフルで使用する場合と 半分以下しか使用しない場合があることを確認しております。帯域を少ししか使用しないためにバックアップ完了が 非常に遅くなっておりま... See more...
DataDomainにてDDBoostを使用し、NBUにて2台のDataDomain間のManaged File Replicationを実行している 環境がございます。当環境においてバックアップのソースファイルによって、WAN帯域をフルで使用する場合と 半分以下しか使用しない場合があることを確認しております。帯域を少ししか使用しないためにバックアップ完了が 非常に遅くなっております。 DataDomainの仕様として、DataDomain間のWAN帯域はthrottleの設定を行っていない場合、常にフルで使用する ものと考えておりましたが異なりますでしょうか?ソースの読み込みのスピードは十分早い前提でお願いいたします。 以上、よろしくお願いいたします。
MFR構成でReplicationジョブの多重度が高い状況では、WANの帯域をほぼ使い切るのに対して 多重度が低い状況ではその1/10程度のスループットで長時間だらだら転送する現象を確認しております。 これは仕様となりますでしょうか? それともReplicationジョブの多重度が低くても帯域を使い切ることが正しい動作となりますでしょうか?
パーツ送信元はEMC社のグローバルのロジスティクスとなりますが、そちらに 確認した方が良いということになりますでしょうか?
MDS9250に対してMDSのWrite Accelerator設定を既存のFCIPインタフェース(MirroView/A用)に設定することは トラフィックの切断無に動的に可能でしょうか?MirrorView/Aの初期同期が中断され、再度Fullsyncが必要となる ことを懸念しております。 以上、よろしくお願いいたします。
DataDomainのパーツナンバー X-2UB-500G が下記で間違いないかどうか確認 いただくことは可能でしょうか? 現物に記載してある表示)    657-0004-0001    P/N: 118032791    MDL: WD1003FBYX-12Y7B0 以上、よろしくお願いいたします。
CX4用のWindows管理PCにCX4にバンドルのモデム(MT9234ZBA)を接続し、EMCRemoteにいよるリモートログイン およびConnectEMCによる自動通報を実施している環境がございます。 本環境において導入当初より継続的に下記の事象が断続的に発生しております。   ・EMC Remoteに接続しようとしても接続不可。  ・モデムに対し電話をかけると、ピ... See more...
CX4用のWindows管理PCにCX4にバンドルのモデム(MT9234ZBA)を接続し、EMCRemoteにいよるリモートログイン およびConnectEMCによる自動通報を実施している環境がございます。 本環境において導入当初より継続的に下記の事象が断続的に発生しております。   ・EMC Remoteに接続しようとしても接続不可。  ・モデムに対し電話をかけると、ピックアップされるがノイズがのっている。  ・以前にもモデム応答不可の事象が複数回発生しているが、その際はモデムのOff/Onや   監視サーバの再起動で復旧している。 毎回、モデムやPCの再起動にて復旧はいたしますが、一度発生いたしますと自動的には復旧いたしません。 どのような原因が考えられますでしょうか?対処方を教えていただくことは可能でしょうか? なお、下記の関連KBを見つけております。 Re: モデム通報の文字化け 以上、よろしくお願いいたします。
下記製品におけるOpenSSHの脆弱性に関しまして確認させてください。 製品: DataDomain(DDOS 5.4) 質問(1) OpenSSHの使用有無 質問(2)使用有の場合 OpenSSHのバージョン 質問(3)使用有の場合 以下のインシデントの影響有無 JVNVU#95595627 OpenSSH のクライアントに複数の脆弱性 URL... See more...
下記製品におけるOpenSSHの脆弱性に関しまして確認させてください。 製品: DataDomain(DDOS 5.4) 質問(1) OpenSSHの使用有無 質問(2)使用有の場合 OpenSSHのバージョン 質問(3)使用有の場合 以下のインシデントの影響有無 JVNVU#95595627 OpenSSH のクライアントに複数の脆弱性 URL: https://jvn.jp/vu/JVNVU95595627/ 以上、よろしくお願いいたします。
下記製品におけるOpenSSHの脆弱性に関しまして確認させてください。 製品: VNX(OE 31) CX4(Flare 28) 質問(1) OpenSSHの使用有無 質問(2)使用有の場合 OpenSSHのバージョン 質問(3)使用有の場合 以下のインシデントの影響有無 JVNVU#95595627 OpenSSH のクライアントに複数の脆弱性 ... See more...
下記製品におけるOpenSSHの脆弱性に関しまして確認させてください。 製品: VNX(OE 31) CX4(Flare 28) 質問(1) OpenSSHの使用有無 質問(2)使用有の場合 OpenSSHのバージョン 質問(3)使用有の場合 以下のインシデントの影響有無 JVNVU#95595627 OpenSSH のクライアントに複数の脆弱性 URL: https://jvn.jp/vu/JVNVU95595627/ 以上、よろしくお願いいたします。
ご回答を大変ありがとうございました。 DDOS5.1では、/backup配下にvtlというサブフォルダがあり、poolを作成するとpool名でのフォルダが 作成されていたかと思いますが、最近のバージョンではpoolを作成するとpool名でのMtreeが作成さ れるような気がいたします。 なお、DDOS5.5でもpool作成時にdirectory poolを作成することは可... See more...
ご回答を大変ありがとうございました。 DDOS5.1では、/backup配下にvtlというサブフォルダがあり、poolを作成するとpool名でのフォルダが 作成されていたかと思いますが、最近のバージョンではpoolを作成するとpool名でのMtreeが作成さ れるような気がいたします。 なお、DDOS5.5でもpool作成時にdirectory poolを作成することは可能のようです。 If you want to create a directory pool (which is backward compatible with the previous version of Data Domain System Manager), select the option "Create a directory backwards compatib ility mode pool. " However, be aware that the advantages of using an MTree pool include the a bility to: ここで、pool replicationのリストアの方法としては下記のようになりますでしょうか? directory poolの場合: 1. recover対象のpoolを削除 2. recover実施 MTree poolの場合: ※ recoverは不可? 1. 対象CTXのbreak(delete pair) 2. 逆同期のpool replicationを作成 以上、よろしくお願いいたします。
VTL構成の2台のDDにてPool Replicationを構成した場合、destination側のDDからsource側のDDへ データをリストアするためには、AdminGuideによるとGUIよりRecoverを実施可能と思います Administration Guide抜粋: Recovering Directory Pool Data Here is how to... See more...
VTL構成の2台のDDにてPool Replicationを構成した場合、destination側のDDからsource側のDDへ データをリストアするためには、AdminGuideによるとGUIよりRecoverを実施可能と思います Administration Guide抜粋: Recovering Directory Pool Data Here is how to recover directory pool data. Procedure 1. Select the More menu, and select Start Recover to display the Start Recover dialog. 2. Select Pool from the Replication Type menu. 3. Select the source system hostname from the System to recover to menu. 4. Select the destination system hostname from the System to recover from menu. 5. Select the context on the destination from which data is recovered. 6. Select OK to start the recovery. ここで、The source must be empty before the recovery can proceed. という注意事項の記載が ございますが、何を空にすれば良いのででしょうか? directoryレプリケーションではcifsなどで該当のフォルダに存在するファイルを全て削除すればよい かと思いますが、Poolでは方法が不明となります。
すみません。もう一点教えてください。 DD2500のソース最大ストリーム数が100とのことですが、下記のドキュメントP152の表 (Data streams sent to a Data Domain system)を確認いたしましたところ、100という数字が 見当たりませんでした。 Data Domain Operating System 5.5 Administrat... See more...
すみません。もう一点教えてください。 DD2500のソース最大ストリーム数が100とのことですが、下記のドキュメントP152の表 (Data streams sent to a Data Domain system)を確認いたしましたところ、100という数字が 見当たりませんでした。 Data Domain Operating System 5.5 Administration Guide https://support.emc.com/docu53504_Data_Domain_Operating_System_5.5_Administration_Guide.pdf?language=en_US 正確にはRepl Source Streamsカラムに記載の90となりますでしょうか? また、ルビに記載のOptDupに関しましてはManaged File Replicationを指しておりますでしょうか? よろしくお願いいたします。
詳細なご説明を大変有難うございました! いただいた情報で現状の説明がつきそうです。 今後ともよろしくお願いいたします。
FIELD INSTALL KITとございますが、物理的な実体の無い型番となりますでしょうか? お客様のラックにマウントするためのラックマウントキットの型番では無いということになりますでしょうか?
ご回答を大変有難うございました! Virtual Syntheticを導入する前では、BKサーバよりソースDDに対してのフルバックアップに17時間程度、 ソースDDからデストDDへの複製に4時間程度を要しておりました。 これをVirtual Syntheticを導入することで、BKサーバよりソースDDに対してのフルバックアップが3時間に 短縮されましたが、複製には6時間と... See more...
ご回答を大変有難うございました! Virtual Syntheticを導入する前では、BKサーバよりソースDDに対してのフルバックアップに17時間程度、 ソースDDからデストDDへの複製に4時間程度を要しておりました。 これをVirtual Syntheticを導入することで、BKサーバよりソースDDに対してのフルバックアップが3時間に 短縮されましたが、複製には6時間と逆に時間を要することとなっております。 以前の複製ではDD間では差分コピーとなっているようにも推測しております。 新旧どちらの構成でもDDBoostとNBUのSLPを用いた複製を実行しており、バックアップ対象データおよび バックアップポリシーは同一です。 なぜ、Virtual Syntheticを導入することで、通常の複製時よりも時間を要するようになってしまったのか? 各環境でのDDのReplicationの内部動作が不明のため、KB203704に記載のDDOS5.5へのアップグレ ードにて現状の問題が解決するかどうかが不明です。 NBUとしてはDDにコマンドをキックした後はノータッチとなりますので、DD側のReplicationのハンドリング にてこのような複製の遅延(通常の複製よりも遅い)が発生していると考えております。 前回質問させていただきました通り、Virtual Syntheticを導入後に複数ジョブを実行した際にも 実行の順番によって複製に要する時間がかなり異なることが分っており、DDの内部動作が不明 なため本KBに該当しているかどうかの判断がつかない状況です。 以下の3通りにおいてDDにて内部的にどのようにreplication(コピー)動作を行っているのかどうか 教えていただけますと幸いです。 1. Virtual Syntheticを導入していない時のDD間のreplicationの動作       -> Block転送での差分コピーとなりますでしょうか? 2. Virtual Syntheticを導入しているが、Virtual Synthetic Duplicationに未対応のDDOSを使用     している場合の、DD間のreplicationの動作       -> Block転送でのフルコピーとなりますでしょうか?その場合、同じ程度の容量のバックアップデータ           を対象とし、2つの複製を同時に実行した場合に要するコピー時間が、4倍異なるということは           一般的には考えられないと思うのですが、容量以外のファイル数などにも、Block Replicationは           依存するのでしょうか?Block転送にも関わらずファイル数に依存するメカニズムが分かるようでしたら           教えていただけますと幸いです。 3. Virtual Syntheticを導入しており、Virtual Synthetic Duplicationが使用可能なDDOSを使用     している場合の、DD間のreplicationの動作      -> Block転送での差分コピーとなりますでしょうか? 以上、大変お手数ですがよろしくお願いいたします。