2014年10月13日
から hiruta
0件のコメント
複数台構成を構築するのに、どの位月額かかるかAWSとさくらのクラウドで試算してみました。
まずは、AWSから
アウトバウンドトラフィック量100Gを想定しています。
計 $79.93 = ￥8,770 (1$=￥110)
次に、さくらのクラウド
計 ￥11,977
AWSの方が安い結果が。その上、さくらのクラウドてAutoScalingに相当するものが自動復旧する仕組みを構築できない。
2014年10月11日
から hiruta
0件のコメント
昨日、RDSのStorageに、General Purpose (SSD)が使えるようになりましたので、早速ディスク性能を計測してみました。
インスタンスタイプは、m3.large、東京リージョンで実施。
General Purpose (SSD)の結果から
$ mysqlslap --no-defaults --concurrency=50 --iterations=1 --number-int-cols=7 --number-char-cols=8 --engine=innodb --auto-generate-sql --auto-generate-sql-add-autoincrement --auto-generate-sql-load-type=key -auto-generate-sql-write-number=1000 --host=rds-stg-webdb.cjjsp36ssxxa.ap-northeast-1.
rds.amazonaws.com --port=3306 --user=root -p webdb
Enter password:
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.065 seconds
Minimum number of seconds to run all queries: 0.065 seconds
Maximum number of seconds to run all queries: 0.065 seconds
Number of clients running queries: 50
Average number of queries per client: 0
Magneticの結果は
$ mysqlslap --no-defaults --concurrency=50 --iterations=1 --number-int-cols=7 --number-char-cols=8 --engine=innodb --auto-generate-sql --auto-generate-sql-add-autoincrement --auto-generate-sql-load-type=key -auto-generate-sql-write-number=1000 --host=rds-stg-webdb.cjjsp36ssxxa.ap-northeast-1.
rds.amazonaws.com --port=3306 --user=root -p webdb
Enter password:
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.075 seconds
Minimum number of seconds to run all queries: 0.075 seconds
Maximum number of seconds to run all queries: 0.075 seconds
Number of clients running queries: 50
Average number of queries per client: 0
簡単な負荷テストで微妙ですが、SSDの方が予想通り速い結果ができました。db.t2.microでもGP (SSD)は使用できます。
ディスクタイプ変更する場合は、7-8 Hour程度かかるとmodify画面の下部に記載されます。
本ブログでも、General Purpose (SSD)を利用しています。
2014年9月21日
から hiruta
0件のコメント
Compute Engine のオートスケール機能を使用してみました。
| Compute Engine Autoscalerは、現在Limit Preview機能ですので、デフォルトでは使用することができませんので、ここからリクエストを申請する必要があります。 |
まずは、Autoscaler機能は現在Limit Previewですので、CLI(gcloud)初期状態はpreview機能は使えませんので以下コマンドを有効にしておきます。
gcloud components update preview
Replica Poolファイルを作成します。AWSでいうLaunch Configurationに相当すると思われます。
vi replica.template
{ "template": {
"vmParams": {
"machineType": "n1-standard-1",
"baseInstanceName": "my-replica",
"disksToCreate": [{
"boot": "true",
"initializeParams": {
"sourceImage": "https://www.googleapis.com/compute/v1/projects/centos-
cloud/global/images/centos-7-v20140903",
"diskSizeGb": "10"
}
}],
"networkInterfaces": [{
"network": "default",
"accessConfigs": [{
"type": "ONE_TO_ONE_NAT",
"name": "External NAT"
}]
}]
}
}
}
上記で作成したReplica Pool configでReplica Poolを作成します。
gcloud preview replica-pools --zone asia-east1-a create --size 1 --template replica.template asia-east1a-pool Replica pool asia-east1a-pool is being created.
replia数を最小値、最大値を1にしてオートスケールの設定をします。
gcloud preview autoscaler --zone asia-east1-a create aisa-east-aurtoscaler --max-num-replicas 1 --min-num-replicas 1 --target-cpu-utilization 0.6 --target https://www.googleapis.com/replicapool/v1beta1/projects/skillful-fx-531/zones/asia-east1-a/pools/asia-east1a-pool
VMインスタンスが起動することが確認できます。そこで、replica数の最小値、最大値を2にしてみます。時間をたたずにもう1つ VMインスタンスが起動できることが確認できます。Replica数を2から1にしても、1 VMインスタンスがterminateされます。
gcloud preview autoscaler --zone asia-east1-a update aisa-east-aurtoscaler --target https://www.googleapis.com/replicapool/v1beta1/projects/skillful-fx-531/zones/asia-east1-a/pools/asia-east1a-pool --max-num-replicas 2 --min-num-replicas 2
ただ、Replica数を0にすることはできないようです。Autoscalerを発動しないようにしておくことはできなそう。
gcloud preview autoscaler --zone asia-east1-a update aisa-east-aurtoscaler --target https://www.googleapis.com/replicapool/v1beta1/projects/skillful-fx-531/zones/asia-east1-a/pools/asia-east1a-pool --max-num-replicas 0 --min-num-replicas 0
<pre>{
"error": {
"errors": [
{
"domain": "global",
"reason": "required",
"message": "Required field not specified: autoscaling_policy.max_num_replicas."
}
],
"code": 400,
"message": "Required field not specified: autoscaling_policy.max_num_replicas."
}
}
SSD Persistent diskに対応していないゾーンで、disk typeにSSD diskを指定するとエラーになります。SSD Persistent diskに対応していないゾーンは、us-central1-aになります。
VMインスタンスを障害をみたてて、「nmcli c down eth0」でインスタンスに接続できない状況を発生させて、自動復旧できるか試してみました。
が、自動復旧されない。Replica PoolにHealthChecksがある。→ここ
使おうとすると、Unknown field nameとなる。？？？
2014年9月7日
から hiruta
0件のコメント
昨日 niftyセミナールームで行われた第4回 コンテナ型仮想化の情報交換会＠東京に参加しました。
コンテナ技術についてインプットが得られた一日でした。
コンテナのリソース管理のキモのCgroupについての話でした。
dockerなどのコンテナではコンテナごとにリソース制御が重要
※AmazonLinux 2013.02、t2.microでリソース Limitを試してみました。
sudo yum install libcgroup
リソース Limitを以下のファイルに記載して、cgconfigサービスを再起動します。CPUをMax 25%に制限する設定になります。
vi /etc/cgconfig.conf
group limittest {
cpu {
cpu.cfs_quota_us = 250000;
cpu.cfs_period_us = 1000000;
}
cpuacct {
}
}
リミッターをかけて、perlbrewのビルドを実施したコマンドになります。
time cgexec -g cpu:limittest /root/perl5/perlbrew/bin/perlbrew install perl-5.18.2
real 44m10.634s
user 9m5.304s
sys 0m29.512s
mixiがLXCをProduction環境（本番環境）に導入した話
まずは、KVMで仮想環境を構築
が、ディスクIO、ディスク容量を多く消費、BIOS依存（IntelVT/AMD-V)などあった。
次に、OpenStack
scriptを使って構築が楽に
いよいよLXC
2013当時はまだ0.X 2014-02にLXC 1.0がリリースされるが、待てないので、0.9で検証開始
Dockerの簡易版といえるmixi運用に必要な機能に絞って独自LXCラッパーtrailerを開発
コンテナ系はCPU他リソースを共有するので、リソース管理が重要
ファイルディスクリプタ、カーネルパラメータのチューニングが必須 ここ にLXCチューニングについて詳しく書かれています。
dockerに最適されたCoreOSについての話
コア部分にはユーザ側でアップデートはできない（OSアップデートは勝手にやってくれる）、追加でアプリケーションを入れることができないので、docker経由でアプリケーションを入れる必要があります。
dockerなどはデータの永続化が難しいので、RDBとかは外部ディスクに保存することが必要。（RDS、Goole Cloud SQLを利用するのもあり）
GCE上で、CoreOSのVMを複数起動させて、Failoverのデモ（当日はうまいかなったようですが）
後日試してみようと思いますので、近日アップデートします。
FreeBSDのjailについて
Solarisコンテナ技術である Oracle Solaris Zoneについて
FreeBSDのjailに実装的に似ている
共通で話されたことが、リソース管理の重要性がありました。
2014年8月16日
から hiruta
0件のコメント
昨日8/15 Engine yardで行われたSendGrid nightに参加しました。
SendGridは決済とかトランザクションメールの処理が得意
ユーザ登録で空メールによる登録を行っているサイトも多々見受けられますが、これにもSendGridのWebhookで実現が可能
Webhookは無料プランでも使えてしまう。無料でもかなり遊べる印象
ruby、php、node.js等のライブラリも充実している
使い方によっては、停止措置を受けてしまうので、使う場合は、ほどほどに
あとは、SendGridのUpdateについて
ここからLT
2014年8月12日
から hiruta
0件のコメント
JAWS-UGさいたまの勉強会かどうかでアンケートに、「IDCFクラウド30日無料トライアル希望」のような項目がありましたので、チェックしたところ、１週間ほど前に、メールで無料クーポンコードが送られてきました。
トライアルでも登録の際、認証があります。電話認証＆国際SNSで行うことができますが、電話認証ネガティブなEnglishなので、聞き間違うことがある。また、国際SNSですが、レスポンスが若干遅かった。
CentOS6.5を使用してみました。
初期起動時は時間がかかる印象。二度目以降は速いようです。SELinuxはデフォルトで無効になっています。
仮想マシンを作るとグローバルIPアドレスが付与されますが、ポートフォワード設定を行わないと、仮想マシンにSSH接続も行えない。
AWSのように、public IP付与するようにすると、仮想マシンに接続できると望ましい。
ディスクはかなり高速な部類。
CPU 「S4 ( 1CPU / 4GB RAM )」※AWSだとm3.medium相当。 メモリ CentOS6.5 # hdparm -t /dev/sda1 /dev/sda1: Timing buffered disk reads: 348 MB in 3.00 seconds = 115.96 MB/sec # hdparm -t /dev/sda1 /dev/sda1: Timing buffered disk reads: 468 MB in 3.01 seconds = 155.68 MB/sec # hdparm -t /dev/sda1 /dev/sda1: Timing buffered disk reads: 516 MB in 3.01 seconds = 171.30 MB/se
ポートベースで設定が行う。SSH、RDP、HTTP、HTTPSとかよく使うプロトコルについては簡易設定のような機能がほしいところ。
2014年7月27日
から hiruta
0件のコメント
先日7/26 松戸市民会館で、JAWS-UG千葉 第4回勉強会 「AWS運用縛り」が開催されました。
クラスメソッド株式会社 植木 和樹さん@czkuk
AWSの運用をどうすべきかのお話。(AWSサポートはすばらしい。「Business サポート」以上)
Management Consoleより、aws-cliの方が手順が作成しやすい。
AWS運用チェックリストもオススメ。ベース文書は英語ですが(Operational Checklists for AWS)、ポイントをhttp://dev.classmethod.jp/cloud/aws/aws-operational-checklist/ にまとめれています。
株式会社DoBoken 磯部 有司さん
ZenClerk http://zenclerk.com/ の運用上の工夫
ZenClerk アーキテクチャ
スポットインスタンスを、100→200と一気に増やすと、全体(リージョン)の相場上がって、全部死( terminate )
開発ツール Slack
Redmineは入力項目多いことで使用していないとこと
監視は、MongoDBの健康状態を第一に考えている (MongoHQ )
運用設計ラボ合同会社 波田野 裕一さん @tcsh
AWS Summit クラウド時代の運用 パネルで視聴しましたが、自動化の前に、構造化設計Why ( ドキュメント）が重要
ドキュメントツール SPHINKの紹介
※ JAWS-UG CLI 支部（ JAWS-UG初の専門支部立ち上げ)
facebook https://www.facebook.com/groups/jaswug.cli/
TIS 株式会社 池田 大輔さん@ike_dai
ログとかは長期の傾向を見る必要があるが、CloudWatchは二週間分しか保存されない。
そこで、Zabbixでの監視
HyClops for Zabbix
HyClops for ZabbixでCloudWatch連携できているのは課金情報のみ。EC2、ELB、RDSについては今後対応予定とのこと
最近リリースされたCloudWatch Logsは、ログのタイムスタンプは注意（ログのタイムスタンプはdatetime_formatで指定)
また、LT 4本も発表されました。
株式会社Syun 高松 基広さん @TadaKazegaFuite
クリエーションライン株式会社 前佛 さん @zembutsu
AWS × Muninの話
株式会社ナレッジコミュニケーション 奥沢 さん
Ｆｌｕｅｎｔｄ を、Kinesisに置き換えた話
Kinesisに置き換えたことで、WEＢサーバーが増えても（スケールアウト)しても、構成変更が必要ない。
KinesisはRedShiftと相性がいいので、ログ分析には最適。先日東京リージョンでもKinesis対応したので、Kinesisの利用事例が増えるのではと予想される。
アマゾン データ サービス ジャパン株式会社 荒木 さん @ar1
2014年7月20日
から hiruta
0件のコメント
7/17、7/18 AWS Summit 2014に参加してきました。JAWS-UG Night Partyその後の二次会まで23時ごろまで、AWSなどクラウドの話で終日盛り上がりました。受講したセッションについて、ポイントを記載します。参加したセッションは主に、Enterprise、Techlogyセッションになります。
OpsWorksの沿革から、仕組み、バックで使用されているChef、デモがありました。OpsWorksはテスト、開発環境をスピーディに構築できる。
ビルドインサポートとして、HAProxy、Node.js、Gangliaなどがある
CloudFormationとの組み合わせ利用ももちろんＯＫ
OpsworksはStage、開発環境構築等に最適
システムのライフサイクルで一番長いフィーズだが運用の位置がここまで評価されていない
レガシー運用、DevOpsでの運用されている方々の話
自動化がブームだが、基本はドキュメントが大事。(Chefレシピ、JSONもドキュメントの一部)
VPCの留意事項
VPCトは16bitが作成できるCIDR。VPCのCIDRは変更できないので、最初に考慮が必要。
※なるべきＣＩＤＲは取得できる限り丸ごと取っておくことが望ましい。
Network ACLsの使い方
共通ポリシなど最小限のポリシを適用しておくのがよい。e.x. 共通で制限できる通信
NATの冗長化、スケールアップ
外向けプロキシ
ＡＺを使った冗長化
CDP候補？ (システム再現パターン、インターネットサービスパターン、内部向けアプリケーションパターン、バックホームパターン)
AWSでサーバー調達等は短くなったが、ミドル、検証テストは時間がかかる
自動化は必要
自動化する上のポイント
自動化コードに問題があった場合の対応
自動化コード規約の必要性
HinemosはAWS APIとの連携 ※IAM Role使えるかはブースの担当者も？？？
Hinemos HA on AWS 9月リリース予定
※有償とのこと 料金は未定
ＡＷＳ導入に至った背景
オンプレだと
休日夜間で即対応不可能 30分～2時間
機会損失、運用コスト
そこで、AWS導入
サーバー構築自動化が必要 (AutoScalling)
機能を詰め込んだＡＭＩを検討したが、サーバーごとに設定が異なるため、その分ＡＭＩが必要。管理が煩雑
Chef receipeで検討。34項目が必要だが、サーバ構築に20分
Ｃｈｅｆ receipeの短縮のため、共通設定は一部AMIを利用することにした。
価格問題
オンデマンドだと価格が
リザーブドも検討したが、インスタンス変更の制約等がある
スポットインスタンス
スポットインスタンスは需要と供給で価格が変わる
スポットインスタンスを入札の変動状況を監視(Zabbix)
入札額が価格を下回ることでサーバー起動しない問題
LaunchConfigurationを複数用意することでConfig切替
アバター合成サーバーの負荷対策
S3マウントだと片系に集中、CPU負荷
GlasterFS
冗長化
ホストベースPeerによるノード追加
ノード生死の自動判別
Serfでノード追加制御(ホストの名前解決)
ログ収集はFluentd、ただし、Fluentd中継サーバーで効率化
AWS導入に至った経由（震災の影響）
顧客情報等個人情報を扱うので、セキュリティを最重要視
店舗、オンプレ、ＡＷＳはDirectConnect及びキャリアIP-VPNでセキュア接続な環境を確保。
店舗端末(iPad)にはデータレス、Radis/個体認証を組み合わせている
随時店舗への導入が随時のため、サーバーサイジング
インスタンスタイプの随時変更
すかいらーく、無印食品、あきんどスシローのクラウドを使用した利用、効果
社内をどう納得させたか
展示ブースにてほぼブースを回りましたが、以前のプレスリリース等から説明員から説明を頂きました。
Montion Board、Tableauなどビックデータ関連の展示も多く見られた。
2014年7月20日
から hiruta
0件のコメント
前日AWS Summitの懇親会、二次会とかなり帰宅(0:00ごろ)が遅くなりましたが、ニフティ本社セミナールームで行われたクラウドを渡り歩け！さくら×ニフティ 合同ハンズオン勉強会！！ に参加しました。
勉強会の流れは以下で進みました。
本ハンズオンセミナーはdockerの基盤の勉強会ではなく、dockerをどう活用するかにポイントを絞ったものになります。docker基盤については、hbstudy等で発表されたslideshareをみるのがいいかと。
実際使用したハンズオン資料は以下に公開されています。
Dockerは、手軽、サーバー使い捨て、クラウド間でlaaS基盤の違いを吸収してしまうすごさをもっていることを改めて実感。ベースOSがUbuntuでもCentOSでも、意識することなくコンテナを構築できる。
さくらのクラウドのアーカイブにCoreOSが対応しているとのこと。CoreOS = Docker専用の軽量Linux
centos:latestとすると、すでに、CentOS7が選択される(CentOS7てPreviewフィーズではなかったか)ので、CentOS6を使う場合は、centos:centos6とする必要がある。
クラウド間マイグレーションは、niftyクラウド、さくらのクラウドにかかわらず動作するはず(GCP、AWS) 。
ただし、IPアドレスを埋め込まれたシステムのマイグレーションは、問題が生じることがあります。例えば、WordPressコンテンツの場合、CSSとかが読み込まれなくなることがある。この点については、DNSの仕組みを組み合わせることで解決できます。
また、docker exportは、コンテナは停止状態で行う必要があります。（フラグでホットスポット状態でもエクスポートできるようになるらしいが推奨されていません。整合性を考えると当たり前か）
ディスカッション時にもでましたが、dockerは、開発、テストには向いていますが、商用運用を行っているのはGoogle位で、まだまだの感。
2014年7月13日
から hiruta
0件のコメント
イメージは、CentOS6(centos-6-v20140619)を、
マシンタイプは、n1-standard-1 (vCPU 1個、メモリ 3.8GB、標準永続ディスク10GB) ※m3.medium相当
インスタンスは同じネットワークに属して行いました。
まず、GCEの東アジアリージョンで、iperf3を使って、スループットを計測してみました。
asia-east-1-a <-> asia-east-1-a(同一ゾーン) :1.7Gbps
asia-east-1-a <-> asia-east-1-b(異なるゾーン) :1.6Gbps
$ iperf3 -c 172.16.219.40 Connecting to host 172.16.219.40, port 5201 [ 4] local 172.16.161.66 port 59195 connected to 172.16.219.40 port 5201 [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-1.00 sec 208 MBytes 1.74 Gbits/sec 0 [ 4] 1.00-2.00 sec 224 MBytes 1.88 Gbits/sec 0 [ 4] 2.00-3.00 sec 222 MBytes 1.87 Gbits/sec 0 [ 4] 3.00-4.00 sec 228 MBytes 1.91 Gbits/sec 0 [ 4] 4.00-5.01 sec 225 MBytes 1.87 Gbits/sec 0 [ 4] 5.01-6.00 sec 223 MBytes 1.88 Gbits/sec 0 [ 4] 6.00-7.01 sec 229 MBytes 1.92 Gbits/sec 0 [ 4] 7.01-8.00 sec 221 MBytes 1.86 Gbits/sec 0 [ 4] 8.00-9.00 sec 224 MBytes 1.88 Gbits/sec 0 [ 4] 9.00-10.01 sec 228 MBytes 1.90 Gbits/sec 0 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-10.01 sec 2.18 GBytes 1.87 Gbits/sec 0 sender [ 4] 0.00-10.01 sec 2.18 GBytes 1.87 Gbits/sec receiver iperf Done.
$ iperf3 -c 172.16.96.191 Connecting to host 172.16.96.191, port 5201 [ 4] local 172.16.161.66 port 46350 connected to 172.16.96.191 port 5201 [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-1.01 sec 213 MBytes 1.77 Gbits/sec 0 [ 4] 1.01-2.00 sec 216 MBytes 1.83 Gbits/sec 0 [ 4] 2.00-3.00 sec 220 MBytes 1.85 Gbits/sec 0 [ 4] 3.00-4.00 sec 217 MBytes 1.82 Gbits/sec 0 [ 4] 4.00-5.00 sec 218 MBytes 1.82 Gbits/sec 0 [ 4] 5.00-6.00 sec 210 MBytes 1.76 Gbits/sec 0 [ 4] 6.00-7.00 sec 221 MBytes 1.86 Gbits/sec 0 [ 4] 7.00-8.00 sec 214 MBytes 1.79 Gbits/sec 0 [ 4] 8.00-9.00 sec 221 MBytes 1.86 Gbits/sec 0 [ 4] 9.00-10.00 sec 222 MBytes 1.86 Gbits/sec 0 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-10.00 sec 2.12 GBytes 1.82 Gbits/sec 0 sender [ 4] 0.00-10.00 sec 2.12 GBytes 1.82 Gbits/sec receiver
予想した通り、同一リージョンより1/10のスループットの結果となりました。
iperf3 -c 172.16.125.92 Connecting to host 172.16.125.92, port 5201 [ 4] local 172.16.161.66 port 49034 connected to 172.16.125.92 port 5201 [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-1.07 sec 512 KBytes 3.91 Mbits/sec 0 [ 4] 1.07-2.13 sec 5.00 MBytes 39.7 Mbits/sec 0 [ 4] 2.13-3.07 sec 14.1 MBytes 125 Mbits/sec 0 [ 4] 3.07-4.07 sec 17.9 MBytes 150 Mbits/sec 0 [ 4] 4.07-5.07 sec 18.9 MBytes 158 Mbits/sec 0 [ 4] 5.07-6.07 sec 16.8 MBytes 141 Mbits/sec 0 [ 4] 6.07-7.07 sec 18.4 MBytes 154 Mbits/sec 0 [ 4] 7.07-8.07 sec 17.6 MBytes 148 Mbits/sec 0 [ 4] 8.07-9.07 sec 18.0 MBytes 151 Mbits/sec 0 [ 4] 9.07-10.07 sec 18.0 MBytes 151 Mbits/sec 0 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-10.07 sec 145 MBytes 121 Mbits/sec 0 sender [ 4] 0.00-10.07 sec 145 MBytes 121 Mbits/sec receiver iperf Done.
同一リージョンであっても、ゾーンが異なる場合、ディスクを使いまわせない
異なるリージョン、ゾーンが異なる場合でも、snapshotからディスクを作成することができます。
参考として、東京リージョン(同一ゾーン)のスループットを計測してみました。
GCEの1/3程度とGCEのネットワークの性能の良さが分かる結果となりました。
$ iperf3 -c 172.16.80.190 Connecting to host 172.16.80.190, port 5201 [ 4] local 172.16.80.111 port 35286 connected to 172.16.80.190 port 5201 [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-1.00 sec 144 MBytes 1.21 Gbits/sec 0 [ 4] 1.00-2.00 sec 35.6 MBytes 299 Mbits/sec 0 [ 4] 2.00-3.00 sec 35.4 MBytes 297 Mbits/sec 0 [ 4] 3.00-4.00 sec 35.4 MBytes 297 Mbits/sec 0 [ 4] 4.00-5.00 sec 35.4 MBytes 297 Mbits/sec 0 [ 4] 5.00-6.00 sec 35.4 MBytes 297 Mbits/sec 0 [ 4] 6.00-7.00 sec 35.4 MBytes 297 Mbits/sec 0 [ 4] 7.00-8.00 sec 35.4 MBytes 297 Mbits/sec 0 [ 4] 8.00-9.00 sec 35.4 MBytes 297 Mbits/sec 0 [ 4] 9.00-10.00 sec 35.4 MBytes 297 Mbits/sec 0 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retransmits [ 4] 0.00-10.00 sec 463 MBytes 388 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 463 MBytes 388 Mbits/sec receiver iperf Done.