DD filesystem restart when cloning VM/VBA

Hi everybody,

we still use Networker 8.2.4 with VBA integration, backup to a DD890 with DD0S 6.01.

When cloning our VM Backups we actually see a strange behavior:

When starting a clone, NMC writes “clone browsing”, Cloning device writes “idle, waiting for writing” and Networker seems to configure his savesets.

After a time (no clones already written) the clone-destination-DataDomain seems to run into a timeout, we get the message “DDFS no heartbeat” and DD filesystem restarts.

This behavior only occures for VMWare clones, all other clones are working fine.

Has anybody seen this before?

Any suggestion would be appreciated.

Best regards,

Christian

Related:

  • No Related Posts

Isaac Asimov: The 4th Law of Robotics

EMC logo


Like me, I’m sure that many of you nerds have read the book “I, Robot.” “I, Robot” is the seminal book written by Isaac Asimov (actually it was a series of books, but I only read the one) that explores the moral and ethical challenges posed by a world dominated by robots.

But I read that book like irobot50 years ago, so the movie “I, Robot” with Will Smith is actually more relevant to me today. The movie does a nice job of discussing the ethical and moral challenges associated with a society where robots play such a dominant and crucial role in everyday life. Both the book and the movie revolve around the “Three Laws of Robotics,” which are:

  • A robot may not injure a human being or, through inaction, allow a human being to come to harm.
  • A robot must obey the orders given to it by human beings except where such orders would conflict with the First Law.
  • A robot must protect its own existence as long as such protection does not conflict with the first or second laws.

It’s like the “3 Commandments” of being a robot; adhere to these three laws and everything will be just fine. Unfortunately, that turned out not to be true (if 10 commandments can not effectively govern humans, how do we expect just 3 to govern robots?).

There is a scene in the movie where Detective Spooner (played by Will Smith) is explaining to Doctor Calvin (who is responsible for giving robots human-like behaviors) why he distrusts and hates robots. He is describing an incident where his police car crashed into another car and both cars were thrown into a cold and deep river – certain death for all occupants. However, a robot jumps into the water and decides to save Detective Spooner over a 10-year old girl (Sarah) who was in the other car. Here is the dialogue between Detective Spooner and Doctor Calvin about the robot’s decision to save Detective Spooner instead of the girl:

Doctor Calvin: “The robot’s brain is a difference engine[1]. It’s reading vital signs, and it must have calculated that…”

Spooner: “It did…I was the logical choice to save. It calculated that I had 45% chance of survival. Sarah had only an 11% chance. She was somebody’s baby. 11% is more than enough. A human being would have known that.”

I had a recent conversation via LinkedIn (see, not all social media conversations are full of fake news) with Fabio Ciucci, the Founder and CEO of Anfy srl located in Lucca, Tuscany, Italy about artificial intelligence and questions of ethics. Fabio challenged me the following scenario:

“Suppose in the world of autonomous cars, two kids suddenly run in front of an autonomous car with a single passenger, and the autonomous car (robot) is forced into a life-and-death decision or choice as to who to kill and who to spare (kids versus driver).”

What decision does the autonomous (robot) car make? It seems Isaac Asimov didn’t envision needing a law to govern robots in these sorts of life-and-death situations where it isn’t the life of the robot versus the life of a human in debate, but it’s a choice between the lives of multiple humans!

A number of surveys have been conducted to understand what to do in a situation where the autonomous car has to make a life-and-death decision between saving the driver versus sparing pedestrians. From the article “Will your driverless car be willing to kill you to save the lives of others?” we get the following:

“In one survey, 76% of people agreed that a driverless car should sacrifice its passenger rather than plow into and kill 10 pedestrians. They agreed, too, that it was moral for autonomous vehicles to be programmed in this way: it minimized deaths the cars caused. And the view held even when people were asked to imagine themselves or a family member travelling in the car.”

While 76% is certainly not an over-whelming majority, there does seem to be the basis for creating a 4th Law of Robotics to govern these sorts of situation. But hold on, while in theory 76% favored saving the pedestrians over the driver, the sentiment changes when it involves YOU!

“When people were asked whether they would buy a car controlled by such a moral algorithm, their enthusiasm cooled. Those surveyed said they would much rather purchase a car programmed to protect themselves instead of pedestrians. In other words, driverless cars that occasionally sacrificed their drivers for the greater good were a fine idea, but only for other people.”

Seems that Mercedes has already made a decision about who to kill and who to spare.  In the article “Why Mercedes’ Decision To Let Its Self-Driving Cars Kill Pedestrians Is Probably The Right Thing To Do”, Mercedes is programming its cars to save the driver and kill the pedestrians or another driver in these no-time-to-hesitant, life-and-death decisions.  Riddle me this, Batman: will how the autonomous car is “programmed” to react in these of life-or-death situations impact your decision to buy a particular brand of autonomous car?

Another study published in the journal “Science” (The social dilemma of autonomous vehicles) highlighted the ethical dilemmas self-driving car manufacturers are faced with, and what people believed would be the correct course of action; kill or be killed. About 2000 people were polled, and the majority believed that autonomous cars should always make the decision to cause the least amount of fatalities. On the other hand, most people also said they would only buy one if it meant their safety was a priority.

4th Law of Robotics

Historically, the human/machine relationship was a master/slave relationship; we told the machine what to do and it did it. But today with artificial intelligence and machine learning, machines are becoming our equals in a growing number of tasks.

I understand that overall, autonomous vehicles are going to save lives…many lives. But there will be situations where these machines are going to be forced to make life-and-death decisions about what humans to save, and what humans to kill. But where is the human empathy that understands that every situation is different?  Human empathy must be engaged to make these types of morally challenging life-and-death decision. I’m not sure that even a 4th Law of Robotics is going to suffice.

 

[1] A difference engine is an automatic mechanical calculator designed to tabulate polynomial functions. The name derives from the method of divided differences, a way to interpolate or tabulate functions by using a small set of polynomial coefficients.

The post Isaac Asimov: The 4th Law of Robotics appeared first on InFocus Blog | Dell EMC Services.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

SPイベントに多数のディスク エラーがある場合の対処方法 (000463306)

バージョン:6 記事タイプ:不具合修正 対象読者:レベル30 = お客様 最終発行日:2016年11月17日木曜日05:53:01(GMT)

概要:

VNX:ソフト メディア エラーがあるSAS/NL_SASドライブをプロアクティブに交換する基準、SPイベントに多数のディスク エラーがある場合の対処方法、801ソフトSCSIバス エラー、820ソフト メディア エラー、6a0ディスク ソフト メディア エラー[復旧済みエラー(オン ドライブECC)]、684パリティ セクターが再構築されました、689セクターが再構築されました

問題:

「ソフト メディア エラー」による不要なディスク交換

VNX:ソフト メディア エラーがあるSAS/NL_SASドライブをプロアクティブに交換する基準

SPイベントに多数のディスク エラーがある場合の対処方法

801 ソフトSCSIバス エラー

820 ソフト メディア エラー

6a0 ディスク ソフト メディア エラー[復旧済みエラー(オン ドライブECC)]

684 パリティ セクターが再構築されました

689 セクターが再構築されました

解決方法:

801ソフトSCSIバス エラー

820 ソフト メディア エラー

6a0 ディスク ソフト メディア エラー[復旧済みエラー(オン ドライブECC)]

684 パリティ セクターが再構築されました

689 セクターが再構築されました

これらのエラーは復旧可能で、ディスク エラーはRAIDによっても保護されます。これらのエラーについては、特別なアクションは不要です。

VNXシステムには、エラー閾値に基づいてディスクを「障害」、「プロベーション」、「プロアクティブなスペアリングが要求されたディスク」、「ディスク交換を推奨」とマークする内部モニタリング プロセスがあります。

どのディスクも「障害/削除済み」、「プロベーション」、「プロアクティブなスペアリングが要求されたディスク」、「ディスク交換を推奨」状態でなく、これらの警告が表示されているだけの場合は、アクションは必要ありません。

注:

同じRG上の2台以上のディスクからほぼ同時に「820ソフト メディア エラー[不良ブロック]」と報告された場合は、修正不能なエラーを防ぐために、このRGの「不良ブロック」エラーの報告数が多いディスクに対して「ホット スペアにコピー」操作を手動で開始してください。「ホット スペアにコピー」操作が完了したら、このディスクを交換します。例外:「不良ブロック」のレポート作成ディスクがviperC(パーツ番号:005049675)の場合は、ETA195555を参照して必要なアクションを確認してください。

あるディスクから「障害/削除済み」、「プロベーション」、「プロアクティブなスペアリングが要求されたディスク」、「ディスク交換を推奨」と報告され、このディスクがこれらのエラーの後に交換されなかった場合は、このディスクを適切な方法でプロアクティブに交換してください。



プライマリ製品: VNX1シリーズ



製品: VNX1シリーズ、VNX2シリーズ

Related:

SNMPが有効化されていて、レプリケーション ライセンスがインストールされているが、レプリケーション コンテキストが構成されていないDDR(Data Domain Restorer)でEnterprise Manager GUIまたはDDSH(Data Domainコマンド ライン)が応答不能になることがある(000463731)

バージョン:4 記事タイプ:不具合修正 対象読者:レベル30 = お客様 最終発行日:2016年7月13日水曜日08:16:31(GMT)

概要: SNMPが有効化されていて、レプリケーション ライセンスがインストールされているが、レプリケーション コンテキストが構成されていないDDR(Data Domain Restorer)でEnterprise Manager GUIまたはDDSH(Data Domainコマンド ライン)が応答不能になることがある

問題:

次のような構成のDDR(Data Domain Restorer)では、さまざまな問題が発生する可能性があります。

SNMPが構成/有効化されている

レプリケーション ライセンスがインストールされている

レプリケーション コンテキストが構成されていない

症状は次のとおりです。

SNMPデーモンが不安定になる(つまり、デーモンのリスタートとそれに対応するアラートが頻繁に発生する)

SMS(System Management Service)デーモンが不安定になるか、異常停止する

SMSに問題が発生した場合、ユーザーはEnterprise Manager GUIやDDSH(Data Domainコマンド ライン インターフェイス)から、DDRを管理できなくなります。たとえば、DDSHでコマンドを実行すると、コマンドが長時間異常停止したり、次のようなエラーが表示されたりする場合があります。

sysadmin@DDVE_57_JF# filesys show space

**** Error retrieving information (**** Error communicating with management service.).

sysadmin@DDVE_57_JF# sysadmin@DDVE_57_JF# filesys show space

**** Error retrieving information (**** Error connecting to management service at “localhost”.).

この問題はDDRの管理のみに影響することに注意してください。通常のバックアップ/リストア作業は、影響を受けるシステムで引き続き実行できます。

原因: SMSデーモンは常にDDR上で実行され、他のデーモンまたはユーザー インターフェイスからの着信接続/コマンドをリスンします。その後、SMSはコマンドを受け取り、システム上で対応するジョブを起動し、クライアント デーモン/ユーザー インターフェイスに結果を返します。そのため、何らかの理由でSMSが利用できない場合、GUI/DDSHからのコマンドはすべて失敗します。

DDRにSNMPが構成されていて、レプリケーション ライセンスがインストールされている場合、SNMPは定期的にSMSデーモンと通信し、構成されているレプリケーション コンテキストのステータスを確認します。この接続は、SNMPプロセスとSMSプロセス間で開いているソケットによって実行されます。DDOS(Data Domain Operating System)内のコードの欠陥により、レプリケーション ライセンスがインストールされているのにレプリケーション コンテキストが構成されていない場合、ソケットは正しく閉じられず、クリーンアップされません。その結果、ソケットはいつまでも開いた(確立した)ままになります(ソケット リーク)。

この問題の結果として、SMSデーモンによって開かれたソケットの数が時間の経過とともに蓄積します。SMSデーモンには、ファイル ディスクリプタ/ソケットを973までしか開くことができないというハード リミットがあります。そのため、すべてのファイル ディスクリプタ/ソケットが使い果たされてしまうと、ユーザー インターフェイスとSMSデーモン間で新しい接続を開いて確立することができなくなります。これはData Domainシステムを管理できなくなることを意味します。

影響を受けるシステムのSMSログ(/ddr/var/log/debug/sms.info)には、次のように、SMSデーモンが開くことができるファイル ディスクリプタ/ソケットの上限に達したことが示されます。

11/16 13:57:33.782 (tid 0x625a320): Rejected connection attempt to port 3006 due to the process fd limit 973.

11/16 13:58:42.827 (tid 0x625a320): Rejected connection attempt to port 3006 due to the process fd limit 973.

11/16 13:59:05.808 (tid 0x625a320): Rejected connection attempt to port 3006 due to the process fd limit 973.

11/16 13:59:21.737 (tid 0x625a320): Rejected connection attempt to port 3006 due to the process fd limit 973.

11/16 13:59:22.739 (tid 0x625a320): Rejected connection attempt to port 3006 due to the process fd limit 973.

さらに、影響を受けるシステムからのオートサポートには、多数の確立済みSMS接続が表示されます(読みやすくするために出力を切り詰めています)。

tcp 0 0 127.0.0.1:3006 127.0.0.1:55419 ESTABLISHED 29263/sms

tcp 0 0 127.0.0.1:3006 127.0.0.1:41968 ESTABLISHED 29263/sms

tcp 0 0 127.0.0.1:3006 127.0.0.1:40082 ESTABLISHED 29263/sms

tcp 0 0 127.0.0.1:3006 127.0.0.1:37200 ESTABLISHED 29263/sms

tcp 0 0 127.0.0.1:3006 127.0.0.1:54457 ESTABLISHED 29263/sms

tcp 0 0 127.0.0.1:3006 127.0.0.1:55106 ESTABLISHED 29263/sms

ポート番号とSNMPデーモンによって開かれた接続を比較すると、これらのソケットがSMSとSNMP間の通信に使用されていることは明らかです。

tcp 0 0 127.0.0.1:55419 127.0.0.1:3006 ESTABLISHED 30108/snmpd

tcp 0 0 127.0.0.1:41968 127.0.0.1:3006 ESTABLISHED 30108/snmpd

tcp 0 0 127.0.0.1:40082 127.0.0.1:3006 ESTABLISHED 30108/snmpd

tcp 0 0 127.0.0.1:37200 127.0.0.1:3006 ESTABLISHED 30108/snmpd

tcp 0 0 127.0.0.1:54457 127.0.0.1:3006 ESTABLISHED 30108/snmpd

tcp 0 0 127.0.0.1:55106 127.0.0.1:3006 ESTABLISHED 30108/snmpd



解決方法: 一時的な軽減:

SNMPおよびSMSデーモンをリスタートして既存のソケット/接続を閉じることで問題を一時的に軽減できます。

# snmp disable

# system show serialno

[system serial number displayed]

# priv set se

[password prompt – enter serial number from above]

# se sms restart

# snmp enable

ただし、次のいずれかの回避策を実施するか、この問題に対する修正をインストールしないと、この問題は一定期間後に再度発生します。

コード修正の詳細:

この問題に対する修正は、次のDDOSリリースに含まれています。

5.5.4.0以降

5.6.2.0以降

5.7.1.0以降

影響を受けるシステムを、修正を含むDDOSリリースにアップグレードする必要があります。そうすれば、それ以上のアクションを実行する必要はありません。

回避策:

すぐにアップグレードできない場合は、次のいずれかの方法で問題を回避できます。

システムからレプリケーション ライセンスを削除する(DDBoostによる管理ファイル レプリケーションを実行しているシステムでは実行しないでください。これらの操作にもレプリケーション ライセンスが必要です)

ダミー レプリケーション コンテキストを作成する(2つのDDRが必要です)

ダミー レプリケーション コンテキストは、次のようにして作成できます。

各DDRでダミーmtreeを作成します。

# mtree create /data/col1/dummy_bug147686

各DDR間にmtreeレプリケーション コンテキストを作成します。

# replication add source mtree://[DDR1]/data/col1/dummy_bug147686 destination

mtree://[DDR2]/data/col1/dummy_bug147686

DDR1でレプリケーション コンテキストを初期化します。

# replication initialize mtree://[DDR2]/data/col1/dummy_bug147686

この問題に対する修正を含むDDOSリリースにシステムをアップグレードしたら、ダミー レプリケーション コンテキストを破棄し、作成したダミーmtreeを削除できます。

各DDRでダミー レプリケーション コンテキストを破棄します。

# replication break mtree://[DDR2]/data/col1/dummy_bug147686

各DDRでダミーmtreeを削除します。

# mtree delete /data/col1/dummy_bug147686

プライマリ製品: Data Domain

製品: Data Domain

エラー コード: DD:SMS

Related:

ScaleIO WindowsまたはScaleIO Linux OSで障害が発生したドライブを交換する方法(000463798)

バージョン:2記事タイプ:不具合修正対象読者:レベル 30 = お客様最終発行日:2016220日土曜日20:56:15GMT

概要:

問題:

ScaleIO環境で障害が発生したドライブを交換する方法を教えてください。

scli –query_sds –sds_ip XX.XX.XX.XX」で次のように出力されました。

SDS 62e70a2e00000005 Name: SDS6

Protection Domain: 3352968300000000, Name: domain1

DRL mode: Volatile

IP information (total 2 IPs):

1: XX.XX.XX.XXRole: SDS Only

2: XX.XX.XX.XXRole: SDC Only

Port: 7072

RAM Read Cache information:

128.0 MB (131072 KB) total size

Cache is enabled

RAM Read Cache memory allocation state is SUCCESSFUL

Number of IO Buffers: 3

Device information (total 22 devices):



….

19: Name: SDS6disks Path: /dev/sds Original-path: /dev/sds ID: b120ed3500050012

Storage Pool: pool1, Capacity: 557 GB Error-fixes: 0 scanned 0 MB, Compare errors: 0 State: Normal

20: Name: SDS6diskv Path: /dev/sdv Original-path: /dev/sdv ID: b120ed3600050013

Storage Pool: pool1, Capacity: 557 GB Error-fixes: 0 scanned 0 MB, Compare errors: 0 State: Error

21: Name: SDS6disku Path: /dev/sdu Original-path: /dev/sdu ID: b120ed3700050014

Storage Pool: pool1, Capacity: 557 GB Error-fixes: 0 scanned 0 MB, Compare errors: 0 State: Normal

22: Name: SDS6diskw Path: /dev/sdw Original-path: /dev/sdw ID: b120ed3800050015

Storage Pool: pool1, Capacity: 557 GB Error-fixes: 0 scanned 0 MB, Compare errors: 0 State: Normal



Membership-state: Joined; Connection-state: Connected; SDS-state: Normal; 1 devices with error



12.0 TB (12273 GB) total capacity

11.1 TB (11366 GB) unused capacity

0 Bytes snapshots capacity

885.3 GB (906528 MB) in-use capacity

0 Bytes thin capacity

556.9 GB (570244 MB) unreachable-unused capacity



解決方法:SDSLinux/Windows OSがある場合の手順を次に示します。

  1. SSHを使用してLinux SDSに接続し、コマンド「fdisk-l」を実行して削除するデバイスを見つけます。Windowsの場合は、ディスクに割り当てられたドライブ文字(D:E:など)を見つけます。
  2. プライマリMDMで次のコマンドを実行して、SDSからデバイスを削除します

コマンド

remove_sds_device

構文

scli–remove_sds_device (–device_id<ID> |

((–sds_id <ID> | —sds_name <NAME> |–sds_ip <IP>)

(–device_name <NAME> | —device_path<PATH>)))

説明/注意

SDSからストレージデバイスの削除を開始します。この処理は非同期で、バックグラウンドで実行されます。

いつでもSDSデバイスを削除でき、ダウンタイムは発生しません。このコマンドの実行時、関連づけられたデータは別のノードにレプリケートされます。

したがって、削除処理は非同期で、長い時間がかかることがあります。abort_remove_sds_deviceコマンドを使用して削除を中止できます。

scli –mdm_ip 192.168.1.200 –remove_sds_device –sds_ip 192.168.1.6 –device_name



/dev/sdb

3.再構築/再バランシングが完了するのを待ちます。手順2で説明したコマンドを実行する前に障害が発生したディスクを物理的に取り外した場合でも、ScaleIOからエントリーを削除できるように手順2で説明したコマンドを実行する必要があります。

4.これで障害が発生したデバイスの交換をベンダーに依頼できます。



5.デバイスを交換したら、コマンドfdisk lを実行して、新しく追加されたデバイス(/dev/sdd/dev/sdeなど)を確認します。

6.デバイスのSDSへの追加

コマンド:-add_sds_device 構文

scli —add_sds_device (–sds_id <ID> |–sds_name <NAME>

|–sds_ip <IP>)device_path <PATH>

[–device_name <NAME>] ((–storage_pool_name<NAME>)

|–storage_pool_id <ID>)[–test_time] [TestOptions]

説明/注意

このコマンドは、指定したSDSに管理されるデバイスにデバイスを追加します。

scli –mdm_ip 192.168.1.200 –add_sds_device -sds_ip 192.168.1.6 storage_pool_name <NAME> –device_path /dev/sdb –device_name sd02

7.ストレージプールにデバイスが追加されると、再バランシングが自動的に始まります。

製品:ScaleIO 1.32ScaleIO 1.32.1ScaleIO 1.32.2ScaleIO 1.32.3

Related:

VPLEX:バージョン5.5 u2以降のESXiホストで、ストレージ デバイスへの接続のランダムな一時的な喪失や、パフォーマンスの低下が発生する(000463942)

バージョン:4

記事タイプ:不具合修正

対象読者:レベル30 = お客様

最終発行日:20161130日水曜日17:09:36GMT

概要:



VMFSハートビートスロットでのATS不一致のため、ESXiホストはデバイスの制御を回復しようとします。そのためホストは、VMFSを保有するLUNに対して、SCSIデバイスのリセットを発行します。このLUNでアクティブなすべてのIOは中止され、SCSIデバイスはリセットされます。接続が一時的に失われたことがVMKernelログに表示されます。

問題

ESXiホストのVMFSデータストアへの接続が、短時間失われます。この期間、データストアのいずれかのVMでクラッシュ、またはIOエラーが発生する場合があります。

VMFS3またはVMFS5データストアで、ESXiホストのCompare & WriteSCSIオペレーションコード89)を使用したハートビートロックの取得要求が、「(ATS) Miscompare during verify operation」のために失敗します。



このVMFSハートビートスロットでのATSAtomic Test & Set)不一致のため、ESXiホストはデバイスの制御を回復しようとします。そのためホストは、VMFSを保有するLUNに対して、

SCSIデバイスのリセットを発行します。

このLUNでアクティブなすべてのIOは中止され、SCSIデバイスはリセットされます。

ATS不一致は、NMPPowerPathの両方で発生する可能性があります。



ホストのVMKernelログに、次のようなイベントが表示されます。

2015-09-30T22:13:55.516Z cpu1:33645)ScsiDeviceIO: 2338: Cmd(0x413686250680) 0x89, CmdSN 0x12b from world 32949 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x0 D:0x2 P:0x0 Valid sense data:0xe 0x1d 0x0.

NMPを保有するホストでは、次のように表示される場合もあります。

2015-09-30T22:13:55.516Z cpu1:33645)NMP: nmp_ThrottleLogForDevice:2321: Cmd 0x89 (0x413686450680, 32949) to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” on path “vmhba2:C0:T5:L13” Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x1d 0x0. Act:NONE

これらのイベントは、VPLEXVMwareハードウェア支援ロック機構(ATS)で使用されるSCSIオペレーションコード89COMPARE AND WRITE)に対応してセンスデータ0E/1D/00ホスト(MISCOMPARE DURING VERIFY OPERATION)に返すことを意味します。







ATSAtomic Test & Set

これは、VMFSボリュームでメタデータを更新するときにSCSI予約の代わりに使用されるロック機構です。基本的にATSロックはディスクセクターを変更するためのメカニズムと見なすことができます。これが成功すると、ESXiホストはVMFS上でメタデータの更新を実行できるようになります。ATSロックでは、プロビジョニング中にVMDKに領域が割り当てられます。ファイルの新しいサイズを反映させるためにメタデータの特定の特性を変更する必要があるからです。興味深いことに、最初のVAAIリリースでは、ATSプリミティブは各ストレージアレイで個別に実装する必要がありました。そのため、ATSオペコードはベンダーによって異なっていました。現在、ATSは標準のT10になり、オペコード0x89COMPARE AND WRITE)を使用します。

VAAIが有効化されたアレイでフォーマットされたVMFS5データストアでは、ハートビットロックにはATSが使用されます。VAAIが有効化されたVMFS5にはSCSI予約はもうありません。ATSは、競合が発生した場合も継続して使用されます。非VAAIアレイでは、VMFS5の重要なセクションを確立する際に、SCS

予約が継続して使用されます。



VPLEXファームウェアログには、次のイベントが表示されます。

ホストHBAのログアウト(tach/38stdf/18)と再ログイン(tach/37stdf/17):



128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:23768:<6>2015/09/18 06:53:24.45: (A0-FC01): login with 0x1234567890123456 (nPortId 0x012345) type TGT is closing. 128.221.252.68/cpu0/log:5988:W/”0060165e9a38102140-2″:46706:<6>2015/09/18 06:53:24.45: (B0-FC01): login with 0x1234567890123456 (nPortId 0x012345) type TGT is closing.



128.221.252.68/cpu0/log:5988:W/”0060165e9a38102140-2″:46707:<4>2015/09/18 06:53:24.45: connection lost. IT: [EXAMPLESERVER_HBA1 (0x1234567890123456) B0-FC01 (0x50001442b035 128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:23769:<4>2015/09/18 06:53:24.45: connection lost. IT: [EXAMPLESERVER_HBA1 (0x1234567890123456) A0-FC01 (0x50001442a035



128.221.252.68/cpu0/log:5988:W/”0060165e9a38102140-2″:46708:<6>2015/09/18 06:53:24.45: (B0-FC01): login with 0x1234567890123456 (nPortId 0x012345) type TGT is ready. 128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:23770:<6>2015/09/18 06:53:24.45: (A0-FC01): login with 0x1234567890123456 (nPortId 0x012345) type TGT is ready. 128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:23771:<4>2015/09/18 06:53:24.45: connection established. IT: [EXAMPLESERVER_HBA1 (0x1234567890123456) A0-FC01 (0x50001 128.221.252.68/cpu0/log:5988:W/”0060165e9a38102140-2″:46709:<4>2015/09/18 06:53:24.45: connection established. IT: [EXAMPLESERVER_HBA1 (0x1234567890123456) B0-FC01 (0x50001



Registered State Change Notification (RSCN) Received (tach/42), due to the Host HBA resets (logouts/logins), preceded by the string “TGT_LGN_FR

128.221.252.68/cpu0/log:5988:W/”0060165e9a38102140-2″:46710:<6>2015/09/18 06:53:26.50: (B0-FC00): finished discovery in 58.650 msec, reason to start: TGT_LGN_FROM_UNKNOWN_NP D, result: succeeded 128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:23772:<6>2015/09/18 06:53:26.52: (A0-FC00): finished discovery in 61.626 msec, reason to start:TGT_LGN_FROM_UNKNOWN_NPID:RSCN_RECEIVED, result: succeeded



通常のRSCN_RECEIVEDメッセージ(tach/42)も想定:

128.221.252.68/cpu0/log:5988:W/”0060165e9a38102140-2″:46711:<6>2015/09/18 06:53:26.64: (B0-FC01): finished discovery in 63.309 msec, reason to start: RSCN_RECEIVED, result: 128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:23773:<6>2015/09/18 06:53:26.66:(A0-FC01): finished discovery in 62.665 msec, reason to start: RSCN_RECEIVED, result



SCSI Operation Code 89 (Compare & Write) Host aborts (stdf/10 with status code starting with “89“):

firmware.log_20150123073924.1:128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:235 11:35:43.15: stdf/10 Scsi Tmf [Abort Task] on fcp ITLQ: [EXAMPLESERVER_HBA1 (0x1234567 A0-FC01 (0x50001442a0353d01) 0x7d000000000000 0x2ed] vol VIRTUAL_VOLUME_NAME_vol taskElapsedTime(usec) 7996921 dormantQCnt 5 enabledQCnt 1 status 8900000000000100:0 firmware.log_20150123073924.1:128.221.252.67/cpu0/log:5988:W/”0060165f237510728-2″:235 11:35:44.15: stdf/10 Scsi Tmf [Abort Task] on fcp ITLQ: [EXAMPLESERVER_HBA1 (0x1234567 A0-FC01 (0x50001442a0353d01) 0x7d000000000000 0x55d] vol VIRTUAL_VOLUME_NAME_vol taskElapsedTime(usec) 929473 dormantQCnt 6 enabledQCnt 1 status 8900000000000100:0



イベントの説明:

tach/38FCログインが閉じます。

stdf/18このログメッセージは、ログアウトまたはファブリックからの離脱によってFCPイニシエータポートの接続が失われるたびに生成されます。

tach/37FCログインはIOを提供する準備ができました。

tach/42最近完了したFC検出のサマリー。

stdf/10ホストがIOを中止します。ホストは、満足できない状況が続く場合は、「論理ユニットリセット」および「ターゲットリセット」TMFにエスカレーションします。

原因:実際には2つの問題があり、両方ともATSハートビート機能によりトリガーされます。

1.EMCを含むさまざまなアレイベンダーが、ESXi 5.5u2で取り込まれたATSハートビート機能の問題を抱えています。

注:VMware KB 2113956では、この問題の影響を受けるESXバージョンはVMware ESXi 5.5.xおよびVMware ESXi 6.0.xとされていますが、具体的なバージョンがすべて明記されているわけではありません。このKBでは、バージョン5.5 u 2以降のすべてのESXiホストとすべてのvSphere 6.0バージョンが影響を受けると想定しています。

VMware vSphereバージョン5.5.0 Update 2(ビルド2068190)以降とvSphere 6.0以降では、VMFSハートビートロックにATSAtomic Test & Set)が使用されます。5.5.0 u2より前のバージョンでは、SCSI-2非永続型予約がこの目的に使用されました。

ホストは、任意のボリュームのハートビートに定期的にI/Oを実行することによってそのライブネスを示します。そのため、ホストのハートビートスロット上で一定期間アクティビティが確認できない場合、ホストはボリュームへの接続を失ったと見なすことができます。

ATSハートビートI/Oは、タイムアウト値が非常に低いため、ホストの切断やアプリケーションの停止を引き起こし、ディスクへの接続の喪失やホストの接続パフォーマンスを低下させる可能性があります。

ホストは、ハートビートスロットの不一致を登録し、LUNがリセットを発行したときにLUNのアクティブIOをすべて破棄します。このLUNの保留中のIOはすべてホストセンス8H:0X8 SCSIリセット)で失敗します。

NMPを使用しているESXiホストからのメッセージの例

2015-10-01T00:31:00.333Z cpu9:33645)NMP: nmp_ThrottleLogForDevice:2321: Cmd 0x89 (0x412e82aeed40, 32805) to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” on path “vmhba2:C0:T5:L10” Failed: H:0x8 D:0x0 P:0x0 Possible sense data: 0x5 0x20 0x0. Act:EVAL

2015-10-01T00:31:00.333Z cpu9:33645)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device “naa.60001440000000XXXXXXXXXXXXXXXXXX” state in doubt; requested fast path state update…

2015-10-01T00:31:00.333Z cpu9:33645)ScsiDeviceIO: 2338: Cmd(0x412e82aeed40) 0x89, CmdSN 0x72b97 from world 32805 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0 Possible sense data: 0x5 0x20 0x0.

2015-10-01T00:31:01.333Z cpu9:33645)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device “naa.60001440000000XXXXXXXXXXXXXXXXXX” state in doubt; requested fast path state update…

2015-10-01T00:31:01.333Z cpu9:33645)ScsiDeviceIO: 2338: Cmd(0x413686ad0b80) 0x89, CmdSN 0x72b9a from world 32805 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0 Possible sense data: 0x5 0x24 0x0.

2015-10-01T00:31:01.406Z cpu9:33645)ScsiDeviceIO: 2307: Cmd(0x41368008ee80) 0x2a, CmdSN 0x8000005d from world 1655292 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0

2015-10-01T00:31:01.406Z cpu9:33645)ScsiDeviceIO: 2307: Cmd(0x413686778800) 0x2a, CmdSN 0x8000004d from world 1655292 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0

2015-10-01T00:31:01.406Z cpu9:33645)ScsiDeviceIO: 2307: Cmd(0x4136838cc140) 0x2a, CmdSN 0x80000049 from world 1655292 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0

2015-10-01T00:31:01.608Z cpu9:33645)ScsiDeviceIO: 2307: Cmd(0x4136848c5c00) 0x2a, CmdSN 0x80000065 from world 1655292 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0

2015-10-01T00:31:01.609Z cpu9:33645)ScsiDeviceIO: 2307: Cmd(0x4136836fde80) 0x2a, CmdSN 0x8000002c from world 1655292 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0

2015-10-01T00:31:01.811Z cpu9:33645)NMP: nmp_ThrottleLogForDevice:2321: Cmd 0x2a (0x4136804206c0, 1655292) to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” on path “vmhba2:C0:T5:L10” Failed: H:0x8 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. Act:EVAL

2015-10-01T00:31:02.014Z cpu9:33645)ScsiDeviceIO: 2307: Cmd(0x4136848cb740) 0x28, CmdSN 0x72b98 from world 34950 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0

2015-10-01T00:31:02.014Z cpu18:34950)HBX: 2832: Waiting for timed out [HB state abcdef02 offset 4161536 gen 297 stampUS 933180151199 uuid 551234ba-5123418f-0123-7123457d566e jrnl <FB 15038> drv 14.60] on vol ‘VPLEX-VOLUME-NAME’

2015-10-01T00:31:02.015Z cpu9:33645)ScsiDeviceIO: 2307: Cmd(0x41368386e100) 0x2a, CmdSN 0x72b99 from world 32805 to dev “naa.60001440000000XXXXXXXXXXXXXXXXXX” failed H:0x8 D:0x0 P:0x0

2015-10-01T00:31:05.675Z cpu9:33039)VMW_SATP_INV: satp_inv_UpdatePath:754: Failed to update path “vmhba3:C0:T5:L10” state. Status Transient storage condition, suggest retry

注:ホストは接続の問題をデバイスに報告します。これは物理的な接続の問題ではなく、ホストからの単一のLUNリセットの結果です。ストレージへのパスの喪失は発生しません。

2.バージョン1.1.58.0-1より前のQLogic qlnativefc HBAドライバには、ATSハートビートに関する重大な問題があります。

このドライバは、アレイのATSハートビート機能に問題がある場合に返されるSCSI ATS不一致センスコードを正しく解釈できず、ホストのマルチパスレイヤー(NMPまたはPowerPath)に適切なメッセージを送り返すことができません。そのため、ESXiカーネルはissコマンドを認識できず、ホストに報告されるメッセージを取得できません。

変更:ESXiバージョン5.5.0 Update 2(ビルド2068190)以降にアップグレードされたホスト。

ESXiバージョン6.0以降にアップグレードされたホスト。

解決方法:

1.EMCを含むさまざまなアレイベンダーが、ESXi 5.5u2で取り込まれたATSハートビート機能の問題を抱えています。

現時点では、EMCアレイの観点からの回避策はありません。お客様は、VMware社に連絡するか、KB 15034に従ってvmsupportEMCgrabを提出して問題を確認してもらうことができます。現在、影響を受けるお客様には、ESXiVAAI ATSハートビート機能を無効にすることを推奨しています。

詳細については、VMware KB 2113956を参照してください。

この機能を無効にすると、ホストはSCSI-2予約レガシーモードに戻ります。



2. QLogic qlnativefc HBAドライバには、ATSハートビートに関する重大な問題があり、ドライババージョン1.1.58.0-1で解決されています。



1.1.58.0-1より前のバージョンのHBA qlnativefcドライバを使用している場合は、qlnativefc 1.1.58.0-1バージョンに更新する必要があります。最新のqlnativefc 1.1.58.0-1ドライバは次のページからダウンロードできます。

https://my.vmware.com/web/vmware/details?downloadGroup=DT-ESXI55-QLOGIC-QLNATIVEFC-11580-1&productId=353



注:この解決策は、VAAI ATSハートビートで使用されるSCSI OpCode 0x89コマンド(COMPARE & WRITE)を実行したときに、VPLEXから不一致(センスデータ0E/1D/00)がホストに返される場合にのみ有効です。それ以外の理由(タイムアウトやホストによる破棄など)で0x89Compare & Write)コマンドが失敗している場合、ソリューションは有効ではありません。この場合は、EMCサポートに連絡することを推奨します。

この記事は、ECNEMCコミュニティネットワーク)上にHVCとしてプロモートされています。https://community.emc.com/docs/DOC-54138

プライマリVPLEXシリーズ

製品:

製品:VPLEXシリーズ、VPLEX GeoVPLEX LocalVPLEX MetroVPLEX VS1VPLEX VS2VPLEX Virtual EditionVPLEX GeoSynchrony 5.1VPLEX GeoS

VPLEX GeoSynchrony 5.1 Patch 2VPLEX GeoSynchrony 5.1 Patch 3VPLEX GeoSynchrony 5.1 Patch 4VPLEX GeoSynchrony 5.2VPLEX GeoS

VPLEX GeoSynchrony 5.2 Service Pack 1VPLEX GeoSynchrony 5.2 Service Pack 1 Patch 1VPLEX GeoSynchrony 5.2 Service Pack 1 Patch 2V

Service Pack 1 Patch 3VPLEX GeoSynchrony 5.3VPLEX GeoSynchrony 5.3 Patch 1VPLEX GeoSynchrony 5.3 Patch 2VPLEX GeoSynchrony 5

GeoSynchrony 5.3 Patch 4VPLEX GeoSynchrony 5.4VPLEX GeoSynchrony 5.4 Service Pack 1VPLEX GeoSynchrony 5.4 Service Pack 1 Pa

Related:

Re: backup oracle db using rman script on client

Hi everyone ,

i’m new to networker , i was using netbackup

i’m trying to backup oracle database using networker , when i was using netbackup it was only one policy ” one work flow “

which excude rman script located on the client side , the rman script on the client contain the tree types of backup ” Full – incremental – archives “

i was running full backup every Friday , incremental daily and archive logs every 3 hours

when the backup policy run from netbackup side according to the schedule type ” Weekly , Daily , archive ” it send the schedule name to rman script which have if statement like ” If you receive Weekly , do Full backup “

This was a good as i have only one policy for each client , and this prevent interfence of backup’s as example when full backup running

and take long time , when the archive log schdule comes to run and found a running full backup it will have to wait

my Question here , can i do this using networker , it was told this it might be complex task and the solution is to make 2 work flow or 3 “Full – incremental – archive ”

but in this situation backup’s might overlap with each other which will make’s backup inconsistent

Thanks in advance

Regards

Related: