Elastic SAN のパフォーマンスを最適化する

この記事では、Azure Elastic SAN を使用する環境で最適なパフォーマンスを得るための一般的なガイダンスを示します。

クライアント側の最適化

一般的な推奨事項

Windows および Linux 仮想マシン

• パフォーマンスを最大限に高めるには、仮想マシン (VM) と Elastic SAN を同じゾーンと同じリージョンにデプロイします。

• Elastic SAN ボリュームへの VM ストレージ I/O では VM ネットワーク帯域幅が使用されるため、VM の従来のディスク スループット制限は Elastic SAN ボリュームには適用されません。 接続されている Elastic SAN ボリュームに対する運用/VM -to-VM I/O と iSCSI I/O に十分な帯域幅を提供できる VM を選択します。 一般に、最適なパフォーマンスを得るための Gen 5 (D/E/M シリーズ) VM を使用する必要があります。

• 作成時に VM で 高速ネットワークを 有効にします。 Azure PowerShell または Azure CLI を使用してこれを行う場合、または既存の VM で高速ネットワークを有効にするには、「Azure PowerShell を使用して高速ネットワークを使用して VM を作成する」を参照してください。

• 最大 IOPS やスループットの制限を実現するには、ボリュームごとにターゲット ボリュームごとに 32 セッションを使用する必要があります。 クライアントでマルチパス I/O (MPIO) を使用して、負荷分散のために各ボリュームへのこれらの複数のセッションを管理します。 スクリプトは、既定で 32 セッションを使用する Azure portal の「ボリュームへの接続」ページや、Windows および Linux で利用可能です。 Windows ソフトウェア iSCSI イニシエーターには、最大 256 セッションの制限があります。 8 つ以上のボリュームを Windows VM に接続する必要がある場合は、必要に応じて各ボリュームへのセッション数を減らします。

Azure VMware ソリューション

• Azure VMware Solution クラスターと同じリージョンと可用性ゾーンに Elastic SAN をデプロイする

• Elastic SAN ボリュームを外部データストアとしてマウントする前にプライベート エンドポイントを構成する

• Azure VMware Solution クラスターに 16 個のノードを含める環境を計画している場合は、使用しているホストに応じて、次のいずれかの構成を使用します。

  • AV36、AV36P、AV52 - 3 つのプライベート エンドポイントに対する 6 つの iSCSI セッション
  • AV64 - 7 つのプライベート エンドポイント上の 7 つの iSCSI セッション

• 環境に 16 個のノードがない場合は、次のいずれかの構成を使用します。

  • AV36、AV36P、AV52 - 4 つのプライベート エンドポイント上の 8 つの iSCSI セッション
  • AV64 - 8 つのプライベート エンドポイントに対する 8 つの iSCSI セッション

  注

  Elastic SAN ボリュームがクラスターに接続されると、すべてのノードに自動的にアタッチされます。 16 個のノードがあり、各ノードが最大接続数 (128) を使用する 8 つの iSCSI セッションを使用するように構成されている場合。 7 つの iSCSI セッションを使用するようにノードを構成すると、(メンテナンスのために) 追加のノードを接続する必要がある場合は、使用可能な iSCSI セッションが確保されます。

• 仮想ディスクの作成時に Eager Zeroed のシック プロビジョニングを使用する

• スループット要件を満たすように ExpressRoute ゲートウェイのサイズを設定する

• Elastic SAN のベース サイズが 16 TiB 以上になるように Elastic SAN を構成して、Elastic SAN データストアのパフォーマンスを最大限に高めることができます

MPIO

ウィンドウズ

次のコマンドを使用して設定を更新します。

# Enable multipath support for iSCSI devices
Enable-MSDSMAutomaticClaim -BusType iSCSI

# Set the default load balancing policy based on your requirements. In this example, we set it to round robin which should be optimal for most workloads.
mpclaim -L -M 2

# Set disk time out to 30 seconds
Set-MPIOSetting -NewDiskTimeout 30

MPIO コマンドレットの詳細については、 MPIO リファレンスを参照してください。

Linux

/etc/multipath.conf ファイルを次のコマンドで更新します。

defaults {
    user_friendly_names yes		# To create ‘mpathn’ names for multipath devices
    path_grouping_policy multibus	# To place all the paths in one priority group
    path_selector "round-robin 0"	# To use round robin algorithm to determine path for next I/O operation
    failback immediate			# For immediate failback to highest priority path group with active paths
    no_path_retry 3			# To disable I/O queueing after retrying once when all paths are down
    polling_interval 5         # Set path check polling interval to 5 seconds
    find multipaths yes        # To allow multipath to take control of only those devices that have multiple paths 
}
devices {
  device {
    vendor "MSFT"
    product "Virtual HD"
  }
}

Azure VMware ソリューション

Microsoft は、Azure VMware Solution の MPIO 設定を管理します。 データストアを作成するときに、最適な値が設定されます。

iSCSI

ウィンドウズ

Windows 上の iSCSI イニシエーターのレジストリ設定を更新します。

1. レジストリ エディターを開きます。
2. [スタート] を選択し、検索ボックスに「regedit」と入力し、Enter キーを押します。
3. 次の場所に移動します: [\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e97b-e325-11ce-bfc1-08002be10318}\0004 (Microsoft iSCSI イニシエーター)\Parameters]
4. 次の設定を更新します。 各設定を右クリックし、[ 変更] を選択します。 [基本] を [10 進数] に変更し、値を更新して [OK] を選択します。

クラスター構成では、ボリュームを共有しているすべてのノードで iSCSI イニシエーター名が一意であることを確認します。 Windows では、iSCSI イニシエーター アプリを使用して更新できます。

1. [スタート] を選択し、検索ボックスで iSCSI イニシエーターを検索します。 これにより、iSCSI イニシエーターが開きます。

2. [構成] を選択すると、現在のイニシエーター名が表示されます。

   

3. 変更するには、[ 変更] を選択し、新しいイニシエーター名を入力して、[OK] を選択します。

   

Linux

ボリュームを接続する前に、クライアントのグローバル iSCSI 構成ファイル (通常は /etc/iscsi ディレクトリにある iscsid.conf) の推奨値で次の設定を更新します。 ボリュームが接続されると、そのノードに固有の構成ファイルと共にノードが作成され (Ubuntu VM など、 /etc/iscsi/nodes/$volume_iqn/portal_hostname,$port ディレクトリにあります)、グローバル構成ファイルから設定が継承されます。 グローバル構成ファイルを更新する前に 1 つ以上のボリュームを既にクライアントに接続している場合は、各ボリュームのノード固有の構成ファイルを直接更新するか、次のコマンドを使用します。

# Variable declaration
volume_iqn=<Elastic SAN volume IQN>
portal_hostname=<Elastic SAN volume portal hostname>
port=3260

# Set maximum data the initiator sends in an iSCSI PDU to the target to 256 KB
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.MaxXmitDataSegmentLength -v 262144

# Set maximum SCSI payload that the initiator negotiates with the target to 256 KB
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.MaxBurstLength -v 262144

# Set maximum unsolicited data the initiator can send in an iSCSI PDU to a target to 256 KB 
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.FirstBurstLength -v 262144

# Set maximum data the initiator can receive in an iSCSI PDU from the target to 256 KB 
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.MaxRecvDataSegmentLength -v 262144

# Disable R2T flow control 
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.InitialR2T -v No

# Enable immediate data
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.ImmediateData -v Yes

# Set timeout value for WMI requests
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].timeo.login_timeout -v 30
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].timeo.logout_timeout -v 15

# Enable CRC digest checking for header and data 
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.HeaderDigest -v CRC32C
sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.DataDigest -v CRC32C 

クラスター構成では、ボリュームを共有しているすべてのノードで iSCSI イニシエーター名が一意であることを確認します。 Linux で、/etc/iscsi/initiatorname.iscsi を変更してイニシエーター名を更新します。

Azure VMware ソリューション

Microsoft は iSCSI 設定を管理します。 データストアを作成するときに、最適な値が設定されます。

エラスティック SAN の最適化

Elastic SAN をデプロイする前に、デプロイする Elastic SAN の最適なサイズを決定して、ワークロードとコストのパフォーマンスの適切なバランスを実現する必要があります。 最適なサイズ設定を決定するには、次の手順に従います。

既存のストレージ ソリューションで、パフォーマンスを追跡する時間間隔 (日/週/四半期) を選択します。 最適な時間間隔は、アプリケーション/ワークロードの適切なスナップショットです。 その期間にわたって、すべてのワークロードの合計最大 IOPS とスループットを記録します。 1 分を超える間隔を使用する場合、またはワークロードのいずれかが現在の構成でボトルネックを抱えている場合は、Elastic SAN デプロイにベース容量を追加することを検討してください。 成長を考慮して、基本容量を決定する際には、余裕を残しておく必要があります。 Elastic SAN のストレージの残りの部分では、コストを節約するために、追加容量を使用する必要があります。

パフォーマンスの詳細については、「 Elastic SAN と仮想マシンのパフォーマンス」を参照してください。