Optimizing storage size of Azure DB for PostgreSQL

  • 投稿日:
  • by
  • カテゴリ:

This article describes how storage size affects the result of benchmarking, pgbench.

The storage size of Azure DB for PostgreSQL is 100 GB by default. It can be enough for your data, but you should know that IOPS is defined with storage size by 3 IOPS per GB. And you should understand the fact that pgbench is just a benchmark as well. It doesn't reflect the real querying pattern from your app. The queries from pgbench are too simple, so the result will be very sensitive for latency. Another I need to mention here is that the minimum IOPS for Azure DB for PostgreSQL is 100 regardless of storage size. Both 5GB and 33GB show a similar result of benchmarking.

I tested with following settings.
PostgreSQL: General Purpose, 4 vCore(s)
Client: Standard F16s (16 vcpus, 32 GiB memory), Ubuntu 18.04

Firstly, inserted 10M records.

$ pgbench -i "host=riopostgres.postgres.database.azure.com port=5432 dbname=postgres user=rifujita@riopostgres password={password} sslmode=require" -s 100

Checked that about 1.5GB data existed after inserting.

postgres=> select datname, pg_size_pretty(pg_database_size(datname)) from pg_database where datname='postgres';
 datname  | pg_size_pretty 
----------+----------------
 postgres | 1503 MB
(1 row)

pgbench command executed

$ pgbench -c 10 -t 1000 "host=riopostgres.postgres.database.azure.com port=5432 dbname=postgres user=rifujita@riopostgres password={password} sslmode=require"

Common parameters through benchmarks

transaction type: 
scaling factor: 100
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000

  • 33 GB(100 IOPS)
    latency average = 91.464 ms
    tps = 109.332645 (including connections establishing)
    tps = 109.800127 (excluding connections establishing)
  • 50 GB(150 IOPS)
    latency average = 60.443 ms
    tps = 165.445682 (including connections establishing)
    tps = 166.176647 (excluding connections establishing)
  • 100 GB(300 IOPS)
    latency average = 34.883 ms
    tps = 286.669194 (including connections establishing)
    tps = 288.647951 (excluding connections establishing)
  • 200 GB(600 IOPS)
    latency average = 29.285 ms
    tps = 341.474144 (including connections establishing)
    tps = 344.244699 (excluding connections establishing)
  • 400 GB(1,200 IOPS)
    latency average = 28.352 ms
    tps = 352.708873 (including connections establishing)
    tps = 355.236614 (excluding connections establishing)
  • 800 GB(2,400 IOPS)
    latency average = 28.632 ms
    tps = 349.256644 (including connections establishing)
    tps = 352.543669 (excluding connections establishing)

Conclusion: From the performance standpoint, the best storage size is 200GB with this querying pattern, and data size, 1.5GB.

CANYONをメンテするには

  • 投稿日:
  • by
  • カテゴリ:

自転車を長く扱ってる人なら当然に所持しているものも多いだろうけれど、CANYONをメンテするにあたって購入したもの等、まとめて備忘録としておく。
Ultimate WMN CF SL Disc 8.0 ETAPの納車以前に購入し、引き続き使用しているものも含めておく。特段断りの無いものはUltimate WMN CF SL Disc 8.0 ETAPで使えるもの。
また、Wiggleや他のサイトの方が安いこともあるので、そちらも是非検索を。

チェーンロックは欲しい強度や携行できる重さなど、色々な基準で好きなのを選ぶと良いけれど、2つ目の盗難防止策として非常に有効なAlterLockは是非装着を。

CANYONのパーツ・オプションはCANYONのウェブサイトから購入するしか無い。
スルーアクスルはデザインがちょっと違うだけでDT SwissのOEM品。フロント100mm、リア142mmで、M12 x 1mmのピッチが切ってあるものであれば、おそらく使える。
ディレイラーハンガー(No.40)は互換品がヤフオクなどに出ていて、それらの中ではPilo D717がまともそう。

タイヤ関連

チューブレスにはしたものの、やはり携行しておくと安心。

ボトル関連

上の2つのボトルケージを付けたが、下のIberaのボトルケージはシートチューブと干渉してしまい取り付けられなかった。

ペダル関連

ディスプレイスタンド

上のIberaのディスプレイスタンドはチェーンステーを支えるタイプなのでどうにか使えるものの、気を付けないとリアのディスクに当たる。下のクイックにはまるタイプは当然役立たず。

バッグ

Ultimate WMN CF SL Disc 8.0 ETAPのヘッドコラムが太いため、このトップチューブバッグはベロクロの長さが不足する。

トップチューブバッグにiPhoneを入れるタイプは、画面内の触ってないところが反応してしまい使い物にならなかった。

ので、iPhoneをステムに固定することに。

iPhoneでずっとやってきたが、バッテリーをトップチューブバッグに入れておかないとならないのも面倒になり、結局サイコンに移行。WAHOO ELEMNT BOLTのアウトフロントマウントは取り付けられず、ひとまずステムマウント。

wahoo_elemnt_bolt_limited_cor.jpgWAHOO ELEMNT BOLT

アウトフロントに付けたいということで、CANYONのCP10に対応するREC-MOUNTSのCANYON2を購入。20200107210504.jpg

工具としては、基本のヘキサとトルクス。トルクスはSRAM FORCEのチェーンリングの分解にT20とT30が、CANYONのディレイラーハンガー、No.40の取り外しにもT25ではなく、T20が必要。デジタルトルクレンチは細かなボルト類に、プレセット型トルクレンチはチェーンリングやディスクローター、クランクの着脱などに。チェーンリングは54Nmの指定があるため、少なくとも60Nmに対応したトルクレンチがオススメ。

T20が含まれるアーレンキーのセットはなかなか少なく、TopeakのX tool+ぐらいしか見つけられなかった。

センターロックディスクローターの着脱用。40Nmが指定されているので、差し込み9.5mmのトルクレンチ → 9.5mm : 24mmソケット → ボスフリー抜きの組み合わせで指定トルクで取り付けられる。

掃除用具

これは自転車に限らないけれど、洗った後に短時間で乾燥させるにはブロアが最適。特にディレイラー周りなどの水滴を残らず吹き飛ばせるので掃除にかかる時間が劇的に短縮できる。コスパ高い。

Zwift関連

上のANT+アダプタに付属するUSB延長ケーブルではちょっと届かず、Amazonベーシックの3mのものを追加。

アクセサリ

ルイガノに上のVOLT200を付けていたが、キャットアイのフレックスタイトブラケットの余った部分を店で切られてしまったため追加購入。これでライトとベルを1本のフレックスタイトブラケットで上下にまとめて装着する。

ロードバイクにハマった

  • 投稿日:
  • by
  • カテゴリ:

Twitterでは散々書いてることなんだけどもブログには書いていなかったので、そろそろまとめておくかという感じで。

今年の9月にルイガノのロードバイクを買った。サイクルベースあさひの在庫処分で本体は68,000円。ヘルメットやポンプ、諸経費込みで10万円以内で収まった。

きっかけは娘ちゃんの自転車の練習。2018年6月に供用した外環道と国道298号の横には歩行者・自転車専用道が整備されたので、そこで娘ちゃんに練習させている時に、ふと「この道で結構遠くまで行けるのでは?」と思ったこと。

20190923110645.jpg

2週間と経たずに、あまりのブレーキ性能の酷さにブレーキだけUltegraにした。

20191006095900.jpg 20191006125013.jpg

10月8日にはContinental Grand Prix 5000に履き替えた。

20191008160944.jpg

SPDペダルにしたりホイールをアルミにしたりしつつ、9月の数日で100km、10月に514km、11月に500km、さらにZwift環境を整えて屋内でのローラー練習も始めた。

20191216201739.jpg

ここまでの時点でメンテの知識もだいぶ身に付いたし工具も大体揃った。フィッティングのような経験のいる作業はともかく、エボIVのメンテや洗濯機の分解、あるいは子供の頃からやってきた機械いじりに慣れていることもあって自転車のメンテ作業に抵抗感はない。

自転車って完全に自分で弄れるのでは?と思い始めたタイミングでもあったので、10.8kgもあるルイガノよりもっと軽くて性能の良い、でも安いのが良いということで12月13日にCANYONのUltimate WMN CF SL Disc 8.0 ETAPを注文し、17日にドイツのフランクフルトから届いた。ステム一体型のハンドルを取り付け、シートポストを差し込み、前輪をスルーアクスルで締め、ペダルを取り付ければ良いだけで、あっけないほど簡単。ディスクブレーキのスペーサーを取り外すのを忘れずに。ペダルはルイガノで使っていて気に入っているシマノのSPDペダル・PD-ES600をCANYONにも。

20191217184753.jpg

さらに輸入したSRAM Force用のパワーメーター、ブランドはSRAMのQUARQになっている、を取り付けた。これは、8mmヘキサで固定されているSRAMのdub規格のチェーンリングを外して、インナー、アウター、オクトパスをT20とT30のトルクスレンチで分解し、オクトパスを入れ替えるだけでパワーとケイデンスがBluetooth / ANT+で取得出来るようになる。$599はリーズナブルだと思う。

20191226200709.jpg 20191227113524.jpg

シートチューブとボトルケージの隙間に写っている黒いパーツは、AlterLock。ある程度高価な、あるいは大事にしているバイクなら絶対付けておくことを強くオススメする。盗まれてもGPSで追跡できる。

Ultimate WMN CF SL Disc 8.0 ETAPについては新しいこともあって色々情報がなく、ひょっとしたら役立つかもしれないのでここにまとめておく。

  • 納車時にSRAM FORCE eTAP AXSのフロントディレイラー、リアディレイラー、左右のシフターがリンクしているかスマホアプリでチェックした方が良い。自分の場合、フロントディレイラーがリンクしていない上、10-33Tが付いて来てるのに、10-26Tが付いてることになってた。
  • スルーアクスルはフロント100mm、リア142mmで、ネジピッチがM12 x 1mmとなっているX-12規格のもの。これがほとんど代替品が無いので、ホイールの交換などを考えているのであれば新車購入時に同時に注文しておくのが良い。でないと、送料11,000円がまた必要になる...。
  • 付属のタイヤはSchwalbe Pro One Evoで、同じくSchwalbeのチューブが入った状態で出荷されてくる。シーラントを別途用意すれば、Reynoldsのホイール用のバルブステム(DT Swiss製?)は付属しているのでチューブレス化が可能。ただし、Schwalbe Pro One Evoの個体差かも知れないけれど、納車から2回目の実走で後輪がパンクし、その後もウォール・トレッドのあちこちからシュワシュワ言い出す始末で信頼出来ないため、とっととContinental Grand Prix 5000 TLにスイッチ。車体色に合わせた赤いTNIのステムでも問題なく使えた。
  • フレームやチェーンステーの傷保護用のシールは最初から貼られているので別途購入の必要はなし。
  • XOSSなどのケイデンスセンサーはクランクに取り付けるクリアランスが全く無いので注意が必要(ということもあって、上記の通りパワーメーターを購入した)。
  • ディレイラーハンガーは、No.40
  • ディスクローターはウェブページには、SRAM Centerline Xと書いてあるけれど、実際にはSRAM Centerline XRが付いて来た。

ブレーキパッドは写真のようなものが付いてくるが、型番が分からず。20191229143849.jpg
色々探してみたところ、サービスマニュアルからパーツナンバーが00.5318.024.000だということが分かった。

今月は実走1,000km超えが、Festive500もあって確定。Zwiftは300kmいくかいかないか...。

追記:Festive500達成。20191229203226.png

Azureの各リージョンに東日本からiperfしてみた

  • 投稿日:
  • by
  • カテゴリ:

自宅からAzureの各リージョンへのiperfでのネットワーク帯域とは別に、Azure東日本から各リージョンへの帯域も計測してみた。東日本にUbuntuを立てて、そこから「VNET peeringをしない」で、各リージョンに立てたUbuntuにiperfをかけるとこんな感じ、と。

「自宅から直接、各リージョンに接続するより、東日本を経由した方が(当然のことながら)高速」
→「VPN Gatewayを東日本に立てて、他のリージョンにアクセスした方が高速」
→でも、それを全部自前で設定するのは面倒だなぁ、ということになるので、Azure Virtual WANの登場、と。

japaneast : 938 Mbits/sec
japanwest : 890 Mbits/sec
koreacentral : 589 Mbits/sec
koreasouth : 458 Mbits/sec
eastasia : 330 Mbits/sec
southeastasia : 211 Mbits/sec
southindia : 201 Mbits/sec
westus2 : 146 Mbits/sec
westus : 132 Mbits/sec
australiaeast : 127 Mbits/sec
australiacentral : 121 Mbits/sec
westcentralus : 109 Mbits/sec
australiasoutheast : 108 Mbits/sec
westindia : 93.4 Mbits/sec
centralus : 87.5 Mbits/sec
southcentralus : 85.1 Mbits/sec
northcentralus : 83.9 Mbits/sec
eastus2 : 81.9 Mbits/sec
eastus : 80.6 Mbits/sec
centralindia : 75.3 Mbits/sec
canadacentral : 69.1 Mbits/sec
uksouth : 65.6 Mbits/sec
canadaeast : 61.2 Mbits/sec
northeurope : 50.6 Mbits/sec
ukwest : 47.3 Mbits/sec
francecentral : 46.9 Mbits/sec
westeurope : 44.3 Mbits/sec
brazilsouth : 39.3 Mbits/sec
southafricanorth : 31.3 Mbits/sec
uaenorth : 19.6 Mbits/sec

Azureの各リージョンにiperfしてみた

  • 投稿日:
  • by
  • カテゴリ:
20190808-iperf.png

自宅(千葉県市川市)から、Azureの各リージョンにiperfを実行するとどのぐらい出ているのかちょっと気になり、以下のようなスクリプトでUbuntuを立ててiperf3をインストールし5201でリッスン、macOSから10秒ずつiperfを実行してみた。なお自宅はauひかりホーム10ギガで接続されており、マルチならAzure東日本に8Gbps程度で繋がる。

#!/bin/bash
  
regions=$(az account list-locations --query [].name -o tsv)
for region in $regions; do
    RG="rifujitademoiperf${region}"
    VM="rifujitaiperf"
    res=$(az group create -l $region -g $RG)
    ipaddress=$(az vm create --image Canonical:UbuntuServer:18.04-LTS:latest --size Standard_D16s_v3 -g $RG -n $VM --query publicIpAddress -o tsv)
    az vm open-port -g $RG -n $VM --port 5201 --priority 1010
    sleep 30
    ssh-keygen -R $ipaddress
    ssh -o "StrictHostKeyChecking no" $ipaddress <<-'EOF'
    sudo apt-get -y install iperf3
    iperf3 -s -D
EOF
    iperf3 -c $ipaddress -t 10 -b 1000M > iperf_$region.txt
    az group delete --no-wait --yes -g $RG
done

結果は以下の通り。1回のみの実行なので、常にこうなるとは言えないけれど、目安程度にはなるかな。

$ grep receiver iperf* | sed 's/^iperf_\([a-z0-9]*\).txt:.* \([0-9\.]* Mbits\/sec\).*$/\1 : \2/' | sort -nr -k3
japaneast : 765 Mbits/sec
japanwest : 185 Mbits/sec
koreacentral : 115 Mbits/sec
koreasouth : 55.2 Mbits/sec
westus2 : 35.2 Mbits/sec
southeastasia : 32.2 Mbits/sec
australiaeast : 30.0 Mbits/sec
southcentralus : 27.0 Mbits/sec
canadaeast : 23.3 Mbits/sec
australiasoutheast : 21.6 Mbits/sec
canadacentral : 21.4 Mbits/sec
centralindia : 21.2 Mbits/sec
westindia : 20.6 Mbits/sec
centralus : 16.3 Mbits/sec
southindia : 15.0 Mbits/sec
northcentralus : 13.4 Mbits/sec
eastasia : 12.7 Mbits/sec
eastus2 : 10.2 Mbits/sec
uaenorth : 7.99 Mbits/sec
brazilsouth : 7.45 Mbits/sec
westcentralus : 6.77 Mbits/sec
westeurope : 6.18 Mbits/sec
francecentral : 5.41 Mbits/sec
westus : 4.96 Mbits/sec
uksouth : 4.60 Mbits/sec
australiacentral : 4.50 Mbits/sec
northeurope : 3.95 Mbits/sec
ukwest : 3.40 Mbits/sec
eastus : 1.35 Mbits/sec
southafricanorth : 1.03 Mbits/sec
# definition for Azure
define("AZ_REGION", "japaneast");
define("VISION_SERVICE_URI", "https://" . AZ_REGION . ".api.cognitive.microsoft.com/vision/v2.0/");
define("OCR_URI", VISION_SERVICE_URI . "ocr");

# definition of VS_API_KEY from Azure Portal or result of az command as follow
# $ az cognitiveservices account keys list -n COG_NAME -g RES_GRP --query key1 -o tsv
define("VS_API_KEY", "API KEY HERE");

# concatenate '.text' in 'words'
function text_concat($words, $item){
	$words .= $item->text;
	return $words;
}

# post an image for Azure Computer Vision OCR
function get_ocr_result($image_path){
	# initiate cURL
	$curl_session = curl_init();
	curl_setopt_array($curl_session,
		array(
			CURLOPT_URL	=>	OCR_URI,
			CURLOPT_POST	=>	true,
			CURLOPT_HTTPHEADER =>	array(
					"Content-Type: application/octet-stream", 
					"Ocp-Apim-Subscription-Key: " . VS_API_KEY
			),
			CURLOPT_POSTFIELDS	=>	file_get_contents($image_path),
			CURLOPT_RETURNTRANSFER	=>	true,
			CURLOPT_BINARYTRANSFER	=>	true,
		)
	);
	$curl_result = curl_exec($curl_session);
	curl_close($curl_session);
	$json = json_decode($curl_result);
	# extract texts(chars) from json
	$res_lines = array();
	$max_height = 0;
	foreach($json->regions as $region){
		foreach($region->lines as $ln_num => $line){
			$tmp = array_reduce($line->words, "text_concat");
			list($d, $d, $d, $height) = explode(",", str_replace('"', "", $line->boundingBox));
			# highest font is used for name
			if($max_height < (int)$height){
				$tmp_len = mb_strlen($tmp);
				if(2 <= $tmp_len && $tmp_len <= 8){
					if(preg_match("/^[\p{Han}\p{Hiragana}\p{Katakana}]+$/u", $tmp)) {
						$max_height = (int)$height;
						$maybe_name = $tmp;
					}
				}
			}
			if(strcmp($maybe_name, $tmp) != 0){
				$res_lines[] = $tmp;
			}
		}
	}
	return array($res_lines, $maybe_name);
}

list($lines_in_image, $maybe_name) = get_ocr_result($tmpfile);
var_dump($lines_in_image);
var_dump($maybe_name);

Azure上のCentOS 7.6のカーネルバージョン一覧を作る

  • 投稿日:
  • by
  • カテゴリ:

Azure IaaSで利用できるCentOS 7.6のカーネルバージョンの一覧を作りたいけれども手作業は面倒。az vm image listの結果からリソースグループとVMを作ってsshでコマンド実行したら、リソースグループごと削除するスクリプト。queryの使い方など、参考になるかと。

#!/bin/bash
  
grp_prefix="riodemocentos"

tmplt="res=\$(az group create -l japaneast -g ${grp_prefix}%s)\n ipaddress=\$(az vm create --image %s --size Standard_F4s_v2 -g ${grp_prefix}%s -n ${grp_prefix}%s -o tsv --query publicIpAddress)\n ssh -t -o \"StrictHostKeyChecking no\" \$ipaddress 'uname -r'\n res=\$(az group delete --yes --no-wait -g ${grp_prefix}%s)\n\n"

urns=$(az vm image list --publisher openlogic --all -o tsv --query "[?starts_with(version, '7.6')].urn")
for urn in $urns; do
        yyyymmdd=$(echo -n $urn | sed 's/.*\([0-9]\{8\}\)$/\1/')
        printf "${tmplt}" ${yyyymmdd} ${urn} ${yyyymmdd} ${yyyymmdd} ${yyyymmdd}
done

実行すると、こういうスクリプトを生成する。そのままパイプでbashに渡しても良いし、リダイレクトしてファイルにしておいても良いかと。

res=$(az group create -l japaneast -g riodemocentos20181219)
 ipaddress=$(az vm create --image OpenLogic:CentOS:7.6:7.6.20181219 --size Standard_F4s_v2 -g riodemocentos20181219 -n riodemocentos20181219 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20181219)

res=$(az group create -l japaneast -g riodemocentos20190402)
 ipaddress=$(az vm create --image OpenLogic:CentOS:7.6:7.6.20190402 --size Standard_F4s_v2 -g riodemocentos20190402 -n riodemocentos20190402 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20190402)

res=$(az group create -l japaneast -g riodemocentos20190708)
 ipaddress=$(az vm create --image OpenLogic:CentOS:7.6:7.6.20190708 --size Standard_F4s_v2 -g riodemocentos20190708 -n riodemocentos20190708 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20190708)

res=$(az group create -l japaneast -g riodemocentos20190306)
 ipaddress=$(az vm create --image OpenLogic:CentOS-CI:7-CI:7.6.20190306 --size Standard_F4s_v2 -g riodemocentos20190306 -n riodemocentos20190306 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20190306)

res=$(az group create -l japaneast -g riodemocentos20190426)
 ipaddress=$(az vm create --image OpenLogic:CentOS-CI:7-CI:7.6.20190426 --size Standard_F4s_v2 -g riodemocentos20190426 -n riodemocentos20190426 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20190426)

res=$(az group create -l japaneast -g riodemocentos20190327)
 ipaddress=$(az vm create --image OpenLogic:CentOS-HPC:7.6:7.6.20190327 --size Standard_F4s_v2 -g riodemocentos20190327 -n riodemocentos20190327 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20190327)

res=$(az group create -l japaneast -g riodemocentos20190529)
 ipaddress=$(az vm create --image OpenLogic:CentOS-HPC:7.6:7.6.20190529 --size Standard_F4s_v2 -g riodemocentos20190529 -n riodemocentos20190529 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20190529)

res=$(az group create -l japaneast -g riodemocentos20190130)
 ipaddress=$(az vm create --image OpenLogic:CentOS-LVM:7-LVM:7.6.20190130 --size Standard_F4s_v2 -g riodemocentos20190130 -n riodemocentos20190130 -o tsv --query publicIpAddress)
 ssh -t -o "StrictHostKeyChecking no" $ipaddress 'uname -r'
 res=$(az group delete --yes --no-wait -g riodemocentos20190130)

CentOS 7.6 on Azure

  • 投稿日:
  • by
  • カテゴリ:

CentOS 7.6にはAzure用にチューニングされたカーネルがあるのだけれど、デフォルトではインストールされていないので以下の手順が必要。

デフォルトでインストールされているカーネルを確認。

$ uname -r
3.10.0-862.11.6.el7.x86_64

これはCentOS 7.5のカーネル。

kernel-azureパッケージをインストール。

$ sudo yum -y install centos-release-azure
$ sudo yum -y install kernel-azure
$ sudo reboot

再起動後、カーネルを再度確認。

$ uname -r
3.10.0-957.21.3.el7.azure.x86_64

いつもと同じようにiperf3でloでテスト。Azure用カーネル、劇的に性能上がる。

# uname -r
3.10.0-957.1.3.el7.x86_64

# iperf3 -c 127.0.0.1 -u -l 16 -b 20M
Connecting to host 127.0.0.1, port 5201
[  4] local 127.0.0.1 port 49703 connected to 127.0.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  1.69 MBytes  14.2 Mbits/sec  110626  
[  4]   1.00-2.00   sec  1.64 MBytes  13.8 Mbits/sec  107513  
[  4]   2.00-3.00   sec  1.94 MBytes  16.2 Mbits/sec  126838  
[  4]   3.00-4.00   sec  1.57 MBytes  13.2 Mbits/sec  103206  
[  4]   4.00-5.00   sec  2.16 MBytes  18.1 Mbits/sec  141488  
[  4]   5.00-6.00   sec  1.80 MBytes  15.1 Mbits/sec  117800  
[  4]   6.00-7.00   sec  1.92 MBytes  16.1 Mbits/sec  125602  
[  4]   7.00-8.00   sec  1.73 MBytes  14.5 Mbits/sec  113292  
[  4]   8.00-9.00   sec  2.06 MBytes  17.3 Mbits/sec  135330  
[  4]   9.00-10.00  sec  2.00 MBytes  16.7 Mbits/sec  130795  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  18.5 MBytes  15.5 Mbits/sec  0.007 ms  352/1212490 (0.029%)  
[  4] Sent 1212490 datagrams

iperf Done.

# iperf3 -c 127.0.0.1 -u -l 16 -b 40M
Connecting to host 127.0.0.1, port 5201
[  4] local 127.0.0.1 port 33688 connected to 127.0.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  1.48 MBytes  12.4 Mbits/sec  96935  
[  4]   1.00-2.00   sec  1.55 MBytes  13.0 Mbits/sec  101492  
[  4]   2.00-3.00   sec  1.62 MBytes  13.6 Mbits/sec  106127  
[  4]   3.00-4.00   sec  1.34 MBytes  11.2 Mbits/sec  87531  
[  4]   4.00-5.00   sec  1.88 MBytes  15.7 Mbits/sec  122992  
[  4]   5.00-6.00   sec  1.35 MBytes  11.3 Mbits/sec  88171  
[  4]   6.00-7.00   sec  1.60 MBytes  13.5 Mbits/sec  105106  
[  4]   7.00-8.00   sec  1.91 MBytes  16.1 Mbits/sec  125484  
[  4]   8.00-9.00   sec  1.72 MBytes  14.4 Mbits/sec  112536  
[  4]   9.00-10.00  sec  1.34 MBytes  11.3 Mbits/sec  88005  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  15.8 MBytes  13.2 Mbits/sec  0.007 ms  58/1034379 (0.0056%)  
[  4] Sent 1034379 datagrams

iperf Done.

# uname -r
3.10.0-957.21.3.el7.azure.x86_64

# iperf3 -c 127.0.0.1 -u -l 16 -b 20M
Connecting to host 127.0.0.1, port 5201
[  4] local 127.0.0.1 port 58778 connected to 127.0.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  2.33 MBytes  19.5 Mbits/sec  152401  
[  4]   1.00-2.00   sec  2.39 MBytes  20.0 Mbits/sec  156379  
[  4]   2.00-3.00   sec  2.23 MBytes  18.7 Mbits/sec  146162  
[  4]   3.00-4.00   sec  2.46 MBytes  20.6 Mbits/sec  161235  
[  4]   4.00-5.00   sec  2.32 MBytes  19.4 Mbits/sec  151733  
[  4]   5.00-6.00   sec  2.53 MBytes  21.2 Mbits/sec  165982  
[  4]   6.00-7.00   sec  2.38 MBytes  20.0 Mbits/sec  156162  
[  4]   7.00-8.00   sec  2.43 MBytes  20.4 Mbits/sec  159078  
[  4]   8.00-9.00   sec  2.32 MBytes  19.5 Mbits/sec  152196  
[  4]   9.00-10.00  sec  2.44 MBytes  20.5 Mbits/sec  160227  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  23.8 MBytes  20.0 Mbits/sec  0.003 ms  0/1561555 (0%)  
[  4] Sent 1561555 datagrams

iperf Done.

# iperf3 -c 127.0.0.1 -u -l 16 -b 40M
Connecting to host 127.0.0.1, port 5201
[  4] local 127.0.0.1 port 43757 connected to 127.0.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  3.55 MBytes  29.8 Mbits/sec  232619  
[  4]   1.00-2.00   sec  3.15 MBytes  26.5 Mbits/sec  206694  
[  4]   2.00-3.00   sec  2.91 MBytes  24.4 Mbits/sec  190630  
[  4]   3.00-4.00   sec  3.62 MBytes  30.4 Mbits/sec  237474  
[  4]   4.00-5.00   sec  3.60 MBytes  30.2 Mbits/sec  235865  
[  4]   5.00-6.00   sec  3.08 MBytes  25.8 Mbits/sec  201622  
[  4]   6.00-7.00   sec  2.96 MBytes  24.8 Mbits/sec  193999  
[  4]   7.00-8.00   sec  3.33 MBytes  27.9 Mbits/sec  218094  
[  4]   8.00-9.00   sec  3.54 MBytes  29.7 Mbits/sec  232162  
[  4]   9.00-10.00  sec  3.51 MBytes  29.4 Mbits/sec  229942  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  33.3 MBytes  27.9 Mbits/sec  0.004 ms  0/2179101 (0%)  
[  4] Sent 2179101 datagrams

iperf Done.

原始的な方法なんだけど、AzureにLinuxのVMを立ててそこにrsyncでバックアップするスクリプト。rsyncdの設定は普通にすればOK。クライアントはrsyncではなく、parsyncfpを使って爆速にする。これをcronで1日1回動かすので、chmod 755とかその辺は適宜設定して欲しい。ストレージをStandard / Premiumで切り替えてコストも最小に抑えてある。

#!/bin/bash

com="parsyncfp --rsyncopts=\"-a\" --chunksize=32M --nowait --NP=32"
par_dir="/opt"
src_dir="/Photos_and_Videos/"

hosts='your_vm_name'
for vm in $hosts; do
	disk=$(az vm show -g ${vm} -n ${vm} -o tsv --query storageProfile.osDisk.name)
	az disk update -g $vm --sku Premium_LRS --name $disk -o table
	dnames=$(az vm show -g ${vm} -n ${vm} -o tsv --query storageProfile.dataDisks[].name)
	for disk in $dnames; do
		az disk update -g $vm --sku Premium_LRS --name $disk -o table
	done
	az vm start -g $vm -n $vm -o table
done

yyyy=$(date +%Y)
for vm in $hosts; do
	vmurl=$(az network public-ip list -g ${vm} --query [].dnsSettings.fqdn -o tsv)
	${com} --startdir="${par_dir}${src_dir}" ${yyyy} rsync://${vmurl}:${src_dir}
done

for vm in $hosts; do
	az vm deallocate -g $vm -n $vm -o table
	disk=$(az vm show -g ${vm} -n ${vm} -o tsv --query storageProfile.osDisk.name)
	az disk update -g $vm --sku Standard_LRS --name $disk -o table
	dnames=$(az vm show -g ${vm} -n ${vm} -o tsv --query storageProfile.dataDisks[].name)
	for disk in $dnames; do
		az disk update -g $vm --sku Standard_LRS --name $disk -o table
	done
done