-
-
-
VMware ESX、Linux KVM、およびCitrix HypervisorでNetScaler ADC VPXのパフォーマンスを最適化する
-
-
Microsoft AzureでNetScaler VPXインスタンスを展開する
-
NetScaler VPX インスタンスでGSLBを構成する
-
PowerShellコマンドを使用して、スタンドアロンモードのNetScaler ADC VPXインスタンスで複数のIPアドレスを構成する
-
NetScalerアプライアンスのアップグレードとダウングレード
-
-
-
-
-
-
-
-
-
-
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
NetScaler VPX インスタンスでGSLBを構成する
グローバルサーバー負荷分散(GSLB)用に構成されたNetScaler ADCアプライアンスは、WANの障害点から保護することにより、ディザスタリカバリとアプリケーションの継続的な可用性を提供します。GSLB は、クライアント要求を最も近い、または最もパフォーマンスの高いデータセンター、または停止が発生した場合に存続しているデータセンターに送信することにより、データセンター間で負荷を分散できます。
このセクションでは、Windows PowerShellコマンドを使用して、Microsoft Azure環境の2つのサイトのVPXインスタンスでGSLBを有効にする方法について説明します。
注
GSLB の詳細については、「 グローバルサーバーの負荷分散」を参照してください。
Azure上のNetScaler VPXインスタンスでGSLBを構成するには、次の2つのステップがあります。
注
複数のNICおよびIPアドレスの構成の詳細については、「 PowerShellコマンドを使用してスタンドアロンモードでNetScaler ADC VPXインスタンスの複数のIPアドレスを構成する」を参照してください。
シナリオ
このシナリオには、2つのサイト(Site 1とSite 2)が含まれています。各サイトのVM(VM1とVM2)には、複数のNIC、複数のIPアドレス、およびGSLBが構成されています。
フィギュア。2つのサイト(Site 1とSite 2)に実装されたGSLBセットアップ
このシナリオでは、各VMには3つのNIC(NIC 0/1、1/1、1/2)が設定されています。各NICに複数のプライベートおよびパブリックIPアドレスを設定できます。これらのNICは次の目的で構成されています。
- NIC 0/1:管理トラフィックを提供する
- NIC 1/1:クライアント側のトラフィックを提供する
- NIC 1/2:バックエンドサーバーと通信する
このシナリオで各 NIC に設定された IP アドレスの詳細については、「 IP 構成の詳細 」セクションを参照してください。
パラメーター
このドキュメントのこのシナリオのサンプルパラメーター設定は、次のとおりです。必要な場合は、異なる設定を使用できます。
$location="West Central US"
$vnetName="NSVPX-vnet"
$RGName="multiIP-RG"
$prmStorageAccountName="multiipstorageaccnt"
$avSetName="MultiIP-avset"
$vmSize="Standard_DS3_V2"
<!--NeedCopy-->
注: VPX インスタンスの最小要件は、2 つの vCPU と 2 GB RAM です。
$publisher="citrix"
$offer="netscalervpx111"
$sku="netscalerbyol"
$version="latest"
$vmNamePrefix="MultiIPVPX"
$nicNamePrefix="MultiipVPX"
$osDiskSuffix="osdiskdb"
$numberOfVMs=1
$ipAddressPrefix="10.0.0."
$ipAddressPrefix1="10.0.1."
$ipAddressPrefix2="10.0.2."
$pubIPName1="MultiIP-pip1"
$pubIPName2="MultiIP-pip2"
$IpConfigName1="IPConfig1"
$IPConfigName2="IPConfig-2"
$IPConfigName3="IPConfig-3"
$IPConfigName4="IPConfig-4"
$frontendSubnetName="default"
$backendSubnetName1="subnet_1"
$backendSubnetName2="subnet_2"
$suffixNumber=10
<!--NeedCopy-->
仮想マシンの作成
PowerShell コマンドを使用して、ステップ 1 ~ 10 に従って、複数の NIC と複数の IP アドレスを使用して VM1 を作成します。
すべての手順とコマンドを完了してVM1を作成した後で、これらの手順を繰り返してVM2固有のパラメーターでVM2を作成します。
リソースグループの作成
New-AzureRMResourceGroup -Name $RGName -Location $location
<!--NeedCopy-->
ストレージアカウントの作成
$prmStorageAccount=New-AzureRMStorageAccount -Name $prmStorageAccountName -ResourceGroupName $RGName -Type Standard_LRS -Location $location
<!--NeedCopy-->
アベイラビリティセットの作成
$avSet=New-AzureRMAvailabilitySet -Name $avSetName -ResourceGroupName $RGName -Location $location
<!--NeedCopy-->
仮想ネットワークの作成
-
サブネットを追加します。
$subnet1=New-AzureRmVirtualNetworkSubnetConfig -Name $frontendSubnetName -AddressPrefix "10.0.0.0/24" $subnet2=New-AzureRmVirtualNetworkSubnetConfig -Name $backendSubnetName1 -AddressPrefix "10.0.1.0/24" $subnet3=New-AzureRmVirtualNetworkSubnetConfig -Name $backendSubnetName2 -AddressPrefix "10.0.2.0/24" <!--NeedCopy-->
-
仮想ネットワークオブジェクトを追加します。
$vnet=New-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $RGName -Location $location -AddressPrefix 10.0.0.0/16 -Subnet $subnet1, $subnet2, $subnet3 <!--NeedCopy-->
-
サブネットを取得します。
$frontendSubnet=$vnet.Subnets|?{$\_.Name -eq $frontendSubnetName} $backendSubnet1=$vnet.Subnets|?{$\_.Name -eq $backendSubnetName1} $backendSubnet2=$vnet.Subnets|?{$_.Name -eq $backendSubnetName2} <!--NeedCopy-->
パブリック IP アドレスの作成
$pip1=New-AzureRmPublicIpAddress -Name $pubIPName1 -ResourceGroupName $RGName -Location $location -AllocationMethod Dynamic
$pip2=New-AzureRmPublicIpAddress -Name $pubIPName2 -ResourceGroupName $RGName -Location $location -AllocationMethod Dynamic
<!--NeedCopy-->
NIC の作成
NIC 0/1の作成
$nic1Name=$nicNamePrefix + $suffixNumber + "-Mgmnt"
$ipAddress1=$ipAddressPrefix + $suffixNumber
$IPConfig1=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName1 -SubnetId $frontendSubnet.Id -PublicIpAddress $pip1 -PrivateIpAddress $ipAddress1 -Primary
$nic1=New-AzureRMNetworkInterface -Name $nic1Name -ResourceGroupName $RGName -Location $location -IpConfiguration $IpConfig1
<!--NeedCopy-->
NIC 1/1の作成
$nic2Name $nicNamePrefix + $suffixNumber + "-frontend"
$ipAddress2=$ipAddressPrefix1 + ($suffixNumber)
$ipAddress3=$ipAddressPrefix1 + ($suffixNumber + 1)
$IPConfig2=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName2 -PublicIpAddress $pip2 -SubnetId $backendSubnet1.Id -PrivateIpAddress $ipAddress2 -Primary
$IPConfig3=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName3 -SubnetId $backendSubnet1.Id -PrivateIpAddress $ipAddress3
nic2=New-AzureRMNetworkInterface -Name $nic2Name -ResourceGroupName $RGName -Location $location -IpConfiguration $IpConfig2, $IpConfig3
<!--NeedCopy-->
NIC 1/2の作成
$nic3Name=$nicNamePrefix + $suffixNumber + "-backend"
$ipAddress4=$ipAddressPrefix2 + ($suffixNumber)
$IPConfig4=New-AzureRmNetworkInterfaceIpConfig -Name $IPConfigName4 -SubnetId $backendSubnet2.Id -PrivateIpAddress $ipAddress4 -Primary
$nic3=New-AzureRMNetworkInterface -Name $nic3Name -ResourceGroupName $RGName -Location $location -IpConfiguration $IpConfig4
<!--NeedCopy-->
VM 設定オブジェクトの作成
$vmName=$vmNamePrefix
$vmConfig=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avSet.Id
<!--NeedCopy-->
認証情報の取得と OS プロパティの設定
$cred=Get-Credential -Message "Type the name and password for VPX login."
$vmConfig=Set-AzureRMVMOperatingSystem -VM $vmConfig -Linux -ComputerName $vmName -Credential $cred
$vmConfig=Set-AzureRMVMSourceImage -VM $vmConfig -PublisherName $publisher -Offer $offer -Skus $sku -Version $version
<!--NeedCopy-->
NICの追加
$vmConfig=Add-AzureRMVMNetworkInterface -VM $vmConfig -Id $nic1.Id -Primary
$vmConfig=Add-AzureRMVMNetworkInterface -VM $vmConfig -Id $nic2.Id
$vmConfig=Add-AzureRMVMNetworkInterface -VM $vmConfig -Id $nic3.Id
<!--NeedCopy-->
OSディスクの指定とVMの作成
$osDiskName=$vmName + "-" + $osDiskSuffix
$osVhdUri=$prmStorageAccount.PrimaryEndpoints.Blob.ToString() + "vhds/" +$osDiskName + ".vhd"
$vmConfig=Set-AzureRMVMOSDisk -VM $vmConfig -Name $osDiskName -VhdUri $osVhdUri -CreateOption fromImage
Set-AzureRmVMPlan -VM $vmConfig -Publisher $publisher -Product $offer -Name $sku
New-AzureRMVM -VM $vmConfig -ResourceGroupName $RGName -Location $location
<!--NeedCopy-->
注
「PowerShell コマンドを使用したマルチ NIC 仮想マシンの作成」に記載されている手順 1~10 を繰り返して、VM2 に固有のパラメータを使用して VM2 を作成します。
IP 構成の詳細
次のIPアドレスを使用します。
テーブル 1. VM1で使用するIPアドレス
NIC | プライベートIP | パブリックIP(PIP) | 説明 |
---|---|---|---|
0/1 | 10.0.0.10 | PIP1 | NSIP(管理IP)として構成 |
1/1 | 10.0.1.10 | PIP2 | SNIP/GSLB サイト IP として設定されています |
- | 10.0.1.11 | - | LB サーバ IP として設定されています。パブリックIPアドレスは必須ではありません |
1/2 | 10.0.2.10 | - | モニタプローブをサービスに送信するための SNIP として設定。パブリック IP は必須ではありません。 |
表2. VM2で使用するIPアドレス
NIC | 内部IP | パブリックIP(PIP) | 説明 |
---|---|---|---|
0/1 | 20.0.0.10 | PIP4 | NSIP(管理IP)として構成 |
1/1 | 20.0.1.10 | PIP5 | SNIP/GSLB サイト IP として設定されています |
- | 20.0.1.11 | - | LB サーバ IP として設定されています。パブリックIPアドレスは必須ではありません |
1/2 | 20.0.2.10 | - | モニタプローブをサービスに送信するための SNIP として設定。パブリック IP は必須ではありません。 |
このシナリオの構成例を次に示します。VM1とVM2のNetScaler VPX CLIで作成されたIPアドレスと初期LB構成を示しています。
VM1 の設定例を次に示します。
add ns ip 10.0.1.10 255.255.255.0 -mgmtAccess ENABLED
Add nsip 10.0.2.10 255.255.255.0
add service svc1 10.0.1.10 ADNS 53
add lb vserver v1 HTTP 10.0.1.11 80
add service s1 10.0.2.120 http 80
Add service s2 10.0.2.121 http 80
Bind lb vs v1 s[1-2]
<!--NeedCopy-->
VM2 の設定例を次に示します。
add ns ip 20.0.1.10 255.255.255.0 -mgmtAccess ENABLED
Add nsip 20.0.2.10 255.255.255.0
add service svc1 20.0.1.10 ADNS 53
add lb vserver v1 HTTP 20.0.1.11 80
Add service s1 20.0.2.90 http 80
Add service s2 20.0.2.91 http 80
Bind lb vs v1 s[1-2]
<!--NeedCopy-->
GSLB サイトおよびその他の設定を構成する
次のトピックで説明するタスクを実行して、2 つの GSLB サイトとその他の必要な設定を構成します。
詳細については、次のサポート記事https://support.citrix.com/article/CTX110348を参照してください。
VM1 および VM2 での GSLB 設定の例を次に示します。
enable ns feature LB GSLB
add gslb site site1 10.0.1.10 -publicIP PIP2
add gslb site site2 20.0.1.10 -publicIP PIP5
add gslb service site1_gslb_http_svc1 10.0.1.11 HTTP 80 -publicIP PIP3 -publicPort 80 -siteName site1
add gslb service site2_gslb_http_svc1 20.0.1.11 HTTP 80 -publicIP PIP6 -publicPort 80 -siteName site2
add gslb vserver gslb_http_vip1 HTTP
bind gslb vserver gslb_http_vip1 -serviceName site2_gslb_http_svc1
bind gslb vserver gslb_http_vip1 -serviceName site1_gslb_http_svc1
bind gslb vserver gslb_http_vip1 -domainName www.gslbindia.com -TTL 5
<!--NeedCopy-->
Azureで実行されているNetScaler VPXインスタンスにGSLBを構成しました。
障害回復
災害(さいがん)とは、自然の災害、または人為的な出来事によって引き起こされる事業機能の突然の混乱である。災害はデータセンターの運用に影響を及ぼします。その後、災害現場で失われたリソースとデータを完全に再構築して復元する必要があります。データ消失やデータセンターのダウンタイムは重要であり、ビジネス継続性が低下します。
お客様が今日直面している課題の1つは、DRサイトをどこに置くかを決めることです。企業は、基盤となるインフラストラクチャやネットワーク障害に関係なく、一貫性とパフォーマンスを求めています。
多くの組織がクラウドへの移行を決定している理由として考えられるのは、次のとおりです。
-
オンプレミスのデータセンターを持つことは非常に高価です。クラウドを使用することで、企業は自社のシステムを拡張する時間とリソースを解放できます。
-
自動オーケストレーションの多くは、より迅速なリカバリを可能にします
-
継続的なデータ保護や継続的なスナップショットを提供してデータを複製し、システム停止や攻撃から保護します。
-
パブリッククラウドにすでに存在しているさまざまな種類のコンプライアンスやセキュリティ制御を顧客が必要とするユースケースをサポートします。これらにより、独自に構築するよりも、必要なコンプライアンスを簡単に達成できます。
GSLB用に構成されたNetScaler ADCは、トラフィックを最も負荷の少ないデータセンターまたは最もパフォーマンスの高いデータセンターに転送します。この構成は、アクティブ-アクティブ設定と呼ばれ、パフォーマンスが向上するだけでなく、セットアップの一部であるデータセンターがダウンした場合に、トラフィックを他のデータセンターにルーティングすることで、ディザスタリカバリを即座に実行できます。これにより、NetScalerはお客様の貴重な時間と費用を節約できます。
災害復旧のためのマルチ NIC マルチ IP (3 つの NIC) の導入
お客様は、セキュリティ、冗長性、可用性、容量、およびスケーラビリティが重要な本番環境に導入する場合、3 つの NIC 導入を使用して導入する可能性があります。この展開方法では、複雑さと管理の容易さはユーザーにとって重大な問題ではありません。
ディザスタリカバリ用の単一NICマルチIP(1NIC)導入
お客様は、以下の理由で非実稼働環境に導入する場合、NIC を 1 つにまとめて導入する可能性があります。
-
テスト用の環境をセットアップするか、本番環境への導入前に新しい環境をステージングします。
-
クラウドに迅速かつ効率的に直接デプロイします。
-
単一のサブネット構成のシンプルさを求めながら。
共有
共有
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.