次の方法で共有

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

  • [アーティクル]

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

クライアント側の最適化

一般的な推奨事項 (Windows と Linux Virtual Machines)

  • 最良のパフォーマンスを実現するには、VM と Elastic SAN を同じゾーンおよび同じリージョンにデプロイします。

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

  • VM の作成時に、VM 上で "高速ネットワーク" を有効にします。 Azure PowerShell または Azure CLI を介して行うか、既存の VM 上で高速ネットワークを有効にする方法については、「Azure PowerShell を使用して、高速ネットワークを設定した VM を作成する」を参照してください。

[高速ネットワークを有効にする] が強調表示されている、VM 作成フローのスクリーンショット。

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

MPIO

Windows

設定を更新するには、次のコマンドを使います。

# 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 1			# To disable I/O queueing after retrying once when all paths are down
}
devices {
  device {
    vendor "MSFT"
    product "Virtual HD"
  }
}

iSCSI

Windows

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

  1. レジストリ エディターを開きます。
  2. [スタート] を選択し、検索ボックスに「regedit」と入力して Enter キーを押します。
  3. レジストリ エントリ [\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e97b-e325-11ce-bfc1-08002be10318}\0004 (Microsoft iSCSI Initiator)\Parameters] に移動します。
  4. 次の設定を更新します。 各設定を右クリックし、[修正] を選択します。 [表記] を [10 進数] に変更し、値を更新して [OK] を選択します。
説明 パラメーターと値
イニシエーターがターゲットへの iSCSI PDU で送信する最大データを 256 KB に設定する MaxTransferLength=262144
イニシエーターがターゲットとネゴシエートする最大 SCSI ペイロードを 256 KB に設定する MaxBurstLength=262144
イニシエーターがターゲットへの iSCSI PDU で送信する最大未承諾データを 256 KB に設定する FirstBurstLength=262144
イニシエーターがターゲットからの iSCSI PDU で受信できる最大データを 256 KB に設定する MaxRecvDataSegmentLength=262144
R2T フロー制御を無効にする InitialR2T=0
即時データを有効にする ImmediateData=1
WMI 要求のタイムアウト値を 30 秒に設定する WMIRequestTimeout = 30 秒
リンク ダウン タイムのタイムアウト値を 30 秒に設定します LinkDownTime = 30 秒

クラスター構成では、ボリュームを共有するすべてのノード間で一意の iSCSI イニシエーター名が必要です。 Windows では、iSCSI イニシエーター アプリで更新できます。

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

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

    Windows での iSCSI イニシエーター構成のスクリーンショット。

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

    Windows での iSCSI イニシエーター名更新のスクリーンショット。

Linux

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

sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n $iscsi_setting_name -v $setting_value

Where

  • $volume_iqn: Elastic SAN ボリュームの IQN
  • $portal_hostname: Elastic SAN ボリューム ポータルのホスト名
  • $port: 3260
  • $iscsi_setting_name: 以下に示す各設定のパラメーター
  • $setting_value: 以下に示す各設定の推奨値
説明 パラメーターと値
# イニシエーターがターゲットへの iSCSI PDU で送信する最大データを 256 KB に設定する node.conn[0].iscsi.MaxXmitDataSegmentLength = 262144
# イニシエーターがターゲットとネゴシエートする最大 SCSI ペイロードを 256 KB に設定する node.session.iscsi.MaxBurstLength = 262144
# イニシエーターがターゲットへの iSCSI PDU で送信する最大未承諾データを 256 KB に設定する node.session.iscsi.FirstBurstLength = 262144
# イニシエーターがターゲットからの iSCSI PDU で受信できる最大データを 256 KB に設定する node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
# R2T フロー制御を無効にする node.session.iscsi.InitialR2T = No
# 即時データを有効にする node.session.iscsi.ImmediateData = Yes
# WMI 要求のタイムアウト値を設定する node.conn[0].timeo.login_timeout = 30

node.conn[0].timeo.logout_timeout = 15
# ヘッダーとデータの CRC ダイジェスト チェックを有効にする node.conn[0].iscsi.HeaderDigest = CRC32C

node.conn[0].iscsi.DataDigest = CRC32C

クラスター構成では、ボリュームを共有するすべてのノード間で一意の iSCSI イニシエーター名が必要です。 Linux では、/etc/iscsi/initiatorname.iscsi に手を加えて、イニシエーター名を更新できます。 Linux での iSCSI イニシエーター名更新のスクリーンショット。

Elastic SAN の最適化

Elastic SAN をデプロイする前に、ワークロードのパフォーマンスとコストの適切なバランスを実現するために、デプロイする Elastic SAN の最適なサイズを決定することが必要です。 次の手順を使用し、最適なサイズを決定します。

既存のストレージ ソリューションで、パフォーマンスを追跡する期間 (日/週/四半期) を選択します。 最適な期間は、アプリケーション/ワークロードのスナップショットとして適切なものです。 その期間中、すべてのワークロードの最大 IOPS とスループットの合計を記録します。 1 分以上の間隔を使用する場合、または現在の構成でボトルネックが発生しているワークロードがある場合は、Elastic SAN のデプロイの基本容量を追加することを検討してください。 基本容量を決定するときは、成長の余地を考慮してある程度のヘッドルームを残しておく必要があります。 Elastic SAN の残りのストレージは、コストを削減するために、追加容量を使用する必要があります。

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