GitHubじゃ!Pythonじゃ!

GitHubからPython関係の優良リポジトリを探したかったのじゃー、でも英語は出来ないから日本語で読むのじゃー、英語社会世知辛いのじゃー

GoogleCloudPlatform

PerfKitBenchmarker – Perfkit Benchmarkerには、クラウド・オファリングを測定して比較するための一連のベンチマークが含まれて..

投稿日:

Perfkit Benchmarkerには、クラウド・オファリングを測定して比較するための一連のベンチマークが含まれています。 ベンチマークでは、デフォルトを使用して、ほとんどのユーザーに表示される内容を反映します。 PerfKit BenchmarkerはApache 2ライセンスの下でライセンスされています。 先に進む前に、ライセンスファイルおよびコントリビューションファイルの内容を読み、理解し、同意することを確認してください。

PerfKitベンチマーカー

PerfKit Benchmarkerは、クラウド・オファリングを測定して比較するための標準的なベンチマーク・セットを定義するためのオープンな作業です。 ベンダー提供のコマンドラインツールを使用して動作するように設計されています。 ベンチマークのデフォルト設定は、特定のプラットフォームまたはインスタンスの種類に合わせて調整されません。 これらの設定は、サービス間の一貫性を保つために推奨されます。 まれに、データベースのバッファプールサイズを設定するなどの一般的な方法がある場合にのみ、設定を変更します。

このREADMEは、ベンチマークを実行するために必要な情報と、コードの操作の基礎を提供するように設計されています。 wikiにはさらに詳しい情報が含まれています:

既知の問題点

ライセンス

PerfKit Benchmarkerは、一般的なベンチマークツールに関するラッパーとワークロード定義を提供します。 私たちは可能な限りすべてを使用し、自動化することを非常に簡単にしました。 選択したクラウドプロバイダーでVMをインスタンス化し、自動的にベンチマークをインストールし、ユーザーの介入なしにワークロードを実行します。

自動化のレベルのため、ベンチマーク実行の一部としてインストールされたソフトウェアのプロンプトは表示されません。 したがって、PerfKit Benchmarkerを使用する前に、各ベンチマークのライセンスを個別に受諾し、使用する責任を負う必要があります。

現在のリリースでは、以下のベンチマークが実行されます。

呼び出されるベンチマークにはJavaが必要です。 また、次のライセンスに同意する必要があります。

CoreMarkの設定を自動化することはできません。 PerfKit Benchmarkerユーザは、Webサイトから手動でCoreMarkのTarballをダウンロードし、 perfkitbenchmarker/dataフォルダ(例: ~/PerfKitBenchmarker/perfkitbenchmarker/data/coremark_v1.0.tgz )に保存するperfkitbenchmarker/dataます。

SPEC CPU2006ベンチマークの設定は自動化できません。 SPECは、ユーザーがライセンスを購入し、利用規約に同意することを要求しています。 PerfKit Benchmarkerユーザーは、SPECのWebサイトからcpu2006-1.2.isoを手動でダウンロードし、 perfkitbenchmarker/dataフォルダ(例: ~/PerfKitBenchmarker/perfkitbenchmarker/data/cpu2006-1.2.iso )に保存し、runspec cfgファイルを提供する必要があります。 ~/PerfKitBenchmarker/perfkitbenchmarker/data/linux64-x64-gcc47.cfg )。 または、PerfKit Benchmarkerは、以下の手順で生成できるtarファイルを受け入れることができます。

  • cpu2006-1.2.isoの内容をcpu2006-1.2.isoという名前のディレクトリに抽出します。
  • cpu2006/install.sh実行します。
  • cfgファイルをcpu2006/configコピーします。
  • cpu2006ディレクトリを含むtarファイルを作成し、 perfkitbenchmarker/dataフォルダ( ~/PerfKitBenchmarker/perfkitbenchmarker/data/cpu2006v1.2.tgz )の下にperfkitbenchmarker/dataます。

PerfKit Benchmarkerは、tarファイルが存在する場合はそれを使用します。 それ以外の場合は、isoファイルとcfgファイルが検索されます。

PerfKitベンチマークのインストールと前提条件

PerfKit Benchmarkerを実行する前に、ベンチマークするクラウドプロバイダのアカウントが必要です。

パスワードのないアカウントにアクセスするためのほとんどのコマンドラインツールと資格情報であるソフトウェアの依存関係も必要です。 次の手順は、CLIツールの認証情報の取得に役立ちます。

Windowsで実行している場合、GitHub Windowsにはopensslsshクライアントなどのツールが含まれているため、インストールする必要があります。 Cygwinには、同じツールが含まれている必要があるため、Cygwinをインストールすることもできます。

Python 2.7とpipをインストールする

Windowsで実行している場合は、Python 2.7の最新バージョンを入手してください これにpipが付いているはずです。 コマンドラインでpythonpip両方を使用できるようにPATH環境変数が設定されていることを確認します(正しいオプションを選択した場合、インストーラがそれを行うことができます)。

ほとんどのLinuxディストリビューションと最近のMac OS XバージョンではすでにPython 2.7がインストールされています。 Pythonがインストールされていない場合は、ディストリビューションのパッケージマネージャを使用してPythonをインストールするか、 Pythonのダウンロードページを参照してください

pipをインストールする必要がある場合は、以下の手順を参照してください

Windowsのみ )GitHub Windowsをインストールする

手順: https : //windows.github.com/

openssl / ssh / scp / ssh-keygenがパス上にあることを確認します( PATH環境変数を更新する必要があります)。 これらのコマンドへのパスは、

C:\\Users\\\<user\>\\AppData\\Local\\GitHub\\PortableGit\_\<guid\>\\bin

PerfKitをインストールする

GitHubからPerfKit Benchmarkerダウンロードしてください。

PerfKit Benchmarkerの依存関係をインストールする

$ cd /path/to/PerfKitBenchmarker
$ sudo pip install -r requirements.txt

事前プロビジョニングされたデータ

一部のベンチマークでは、データをクラウド内で事前にプロビジョニングする必要がある場合があります。 データを事前にプロビジョニングするには、データを取得してそのクラウドにアップロードする必要があります。 どのベンチマークに事前プロビジョニングされたデータが必要か、それを別のクラウドにアップロードする方法については、以下の情報を参照してください。

注意。 事前プロビジョニングされたデータに切り替える前に、PerfKitBenchmarkerを実行するマシンのdata /ディレクトリにファイルをダウンロードするフォールバック戦略をサポートする必要があります(今日のCoreMarkとSPEC CPU2006のように)。

クラウドアカウントの設定

このセクションでは、各クラウドシステムに必要なセットアップ手順について説明します。 テストするクラウドに対してセットアップ手順を実行するだけでよいことに注意してください。 Google Cloudのみをテストする場合は、 gcloudをインストールして設定する必要があります。

使用するクラウドを設定した後、オブジェクトベンチマークを使用する場合を除いて、単一のベンチマークの実行にスキップしてください。その場合は、botoファイル構成する必要があります

gcloudをインストールして認証を設定する

手順: https : //developers.google.com/cloud/sdk/ OS XまたはLinuxを使用している場合、以下のコマンドを実行できます:

$ curl https://sdk.cloud.google.com | bash

プロンプトが表示されたら、ローカルフォルダ、Pythonプロジェクト、残りのすべてのデフォルトを選択します。

シェルウィンドウを再起動します(またはVM上で実行している場合は再度logout / sshを実行します)

Windowsの場合は、同じページにアクセスして、ページのWindowsのインストール手順に従います。

次に、 Google Cloud Consoleにアクセスしてプロジェクトを作成します。 その後、次のコマンドを実行します。

$ gcloud init

これは、認証、プロジェクトの設定、およびデフォルトの設定に役立ちます。

あるいは、すでに設定されていて、認証が必要な場合は、次のコマンドを使用できます。

$ gcloud auth login

ヘルプについては、 gcloud docsを参照してください。

OpenStack CLIクライアントのインストールと認証の設定

pipがインストールされていることを確認してください(上記のセクションを参照)。

次のコマンドでOpenStack CLIユーティリティをインストールします。

$ sudo pip install -r perfkitbenchmarker/providers/openstack/requirements.txt

資格情報とエンドポイント情報を設定するには、OpenStack RCファイルを使用して環境変数を設定するだけです。 ヘルプについては、 OpenStackドキュメントを参照してください。

Kubernetesの構成と資格情報

PerfkitはKubernetesクラスタと通信するためにkubectlバイナリを使用します。 – --kubectlフラグを使用してkubectlバイナリにパスを渡す必要があります。 バージョン1.0.1を使用することをお勧めします。 Kubernetesクラスタへの認証は、 kubeconfigファイルを介して行われます そのパスは--kubeconfigフラグを使用して--kubeconfigます。

イメージの前提条件
Dockerベースの雲に関する画像の前提条件を参照してください。

Kubernetesクラスタ構成
KubernetesクラスタがCoreOS上で動作している場合:

  1. $PATH環境変数を修正して、適切なバイナリが見つかるようにしてください:

    $ sudo mkdir /etc/systemd/system/kubelet.service.d
    $ sudo vim /etc/systemd/system/kubelet.service.d/10-env.conf

    [Service]セクションに次の行を追加します。

    Environment=PATH=/opt/bin:/usr/bin:/usr/sbin:$PATH
    
  2. ノードを再起動します。

    $ sudo reboot

一部のベンチマークは特権付きコンテナ内で実行する必要があります。 デフォルトでは、Kubernetesはコンテナーを特権モードでスケジュールすることを許可していません – --allow-privileged=true kube-apiserverと各kubeletスタートアップコマンドに--allow-privileged=trueフラグを追加する必要があります。

セフ統合
標準スクラッチディスクタイプ( --scratch_disk_type=standard – これはデフォルトオプション)でベンチマークを実行すると、Cephストレージが使用されます。 Cephボリュームを使用してKubernetes PODを作成するには、いくつかの設定手順が必要です。 各Kubernetesノード、およびPerfkitベンチマークを実行しているマシンで、次の操作を行います。

  1. Ceph-hostから/etc/ceph cephディレクトリをコピーします。

  2. rbdコマンドが利用できるようにrbd ceph-commonパッケージをインストールしてrbd

  • あなたのKubernetesクラスタがCoreOS上で動作している場合、 rbdコンテナ内でrbdコマンドを実行するrbdというbashスクリプトを作成する必要があります:

    #!/usr/bin/bash
    /usr/bin/docker run -v /etc/ceph:/etc/ceph -v /dev:/dev -v /sys:/sys  --net=host --privileged=true --rm=true ceph/rbd $@

    ファイルをrbdとして保存し、 rbdを実行します。

    $ chmod +x rbd
    $ sudo mkdir /opt/bin
    $ sudo cp rbd /opt/bin

    rbdmapをインストールします。

    $ git clone https://github.com/ceph/ceph-docker.git
    $ cd ceph-docker/examples/coreos/rbdmap/
    $ sudo mkdir /opt/sbin
    $ sudo cp rbdmap /opt/sbin
    $ sudo cp ceph-rbdnamer /opt/bin
    $ sudo cp 50-rbd.rules /etc/udev/rules.d
    $ sudo reboot

利用可能なCeph認証オプション2つあります。

  1. --ceph_keyring--ceph_keyringフラグを使用して鍵リングファイルにパスを渡す

  2. 秘密。 この場合、最初に秘密を作成する必要があります:

    Base64でエンコードされたCeph管理キーを取得する:

    $ ceph auth get-key client.admin | base64
    QVFEYnpPWlZWWnJLQVJBQXdtNDZrUDlJUFo3OXdSenBVTUdYNHc9PQ==  

    create_ceph_admin.ymlというファイルを作成し、 key値を前のコマンドの出力に置き換えます。

    apiVersion: v1
    kind: Secret
    metadata:
      name: my-ceph-secret
    data:
      key: QVFEYnpPWlZWWnJLQVJBQXdtNDZrUDlJUFo3OXdSenBVTUdYNHc9PQ==

    Kubernetesに秘密を加える:

    $ kubectl create -f create_ceph_admin.yml

    --ceph_secret実行するときに、秘密の名前( --ceph_secretフラグを使用)を--ceph_secret必要があります。 この場合は--ceph_secret=my-ceph-secretでなければなりません。

メゾス構成

MesosプロバイダはDockerインスタンスを管理するためにMarathonフレームワークと通信します。 したがって、MesosクラスタとともにMarathonフレームワークをセットアップする必要があります。 --marathon_addressに接続するには、 – --marathon_addressフラグを使ってMarathonフレームワークにIPアドレスとポートを提供する必要があります。

プロバイダは、Mesos v0.24.1およびMarathon v0.11.1でテスト済みです。

オーバーレイネットワーク
Mesos自体は、オーバーレイネットワーキングのためのソリューションを提供していません。 インスタンスが同じネットワーク上に存在するようにクラスタを構成する必要があります。 この目的のために、フランネル、キャリコ、ウィーブなどを使用することができます。

メゾスクラスタ構成
Mesos-slaveノードが、ベンチマークの実行に使用されているマシンから(ホスト名によって)到達可能であることを確認してください。 そうでない場合は、 /etc/hostsファイルを適切に編集してください。

イメージの前提条件
Dockerベースの雲に関する画像の前提条件を参照してください。

Cloudstack:依存関係をインストールし、APIキーを設定する

$ sudo pip install -r perfkitbenchmarker/providers/cloudstack/requirements.txt

CloudstackからAPIキーとSECRETを取得します。 次の環境変数を設定します。

export CS_API_URL=<insert API endpoint>
export CS_API_KEY=<insert API key>
export CS_API_SECRET=<insert API secret>

ベンチマーク実行時のネットワーク提供を指定します。 VPC(– --cs_use_vpc )を使用する場合は、VPCオファリング( --cs_vpc_offering )も指定します。

$ ./pkb.py --cloud=CloudStack --benchmarks=ping --cs_network_offering=DefaultNetworkOffering

AWS CLIとセットアップ認証をインストールする

pipがインストールされていることを確認してください(上記のセクションを参照)。

http://aws.amazon.com/cli/の指示に従うか、次のコマンドを実行します(Windowsでは「sudo」を省略します)

$ sudo pip install -r perfkitbenchmarker/providers/aws/requirements.txt

AWSコンソールにアクセスして、アクセスクレデンシャルを作成します: https : //console.aws.amazon.com/ec2/

  • コンソール上であなたの名前をクリックしてください(左上)
  • [セキュリティ資格情報]をクリックします。
  • 「アクセスキー」をクリックし、新しいアクセスキーを作成します。 ファイルをダウンロードすると、サービスにアクセスするためのアクセスキーと秘密鍵が含まれています。 値をメモし、ファイルを削除します。

前の手順のキーを使用してCLIを設定します。

$ aws configure

Windows Azure CLIと資格情報

まずnode.jsとNPMをインストールする必要があります。 このバージョンのPerfkit Benchmarkerは、Azure CLIバージョン0.10.4と互換性があることが知られており、これより新しいバージョンでも動作する可能性があります。

ここに行き、セットアップの指示に従います。

次に、次のsudoを実行します(Windowsではsudoを省略します)。

$ sudo npm install azure-cli -g
$ azure login

azureが正しくインストールされていることをテストします。

$ azure vm list

最後に、Azureがリソース管理モードになっていることと、アカウントにAzureのVMとネットワークを割り当てる権限があることを確認してください。

$ azure config mode arm
$ azure provider register Microsoft.Compute
$ azure provider register Microsoft.Network

AliCloud CLIとセットアップ認証をインストールする

pipがインストールされていることを確認してください(上記のセクションを参照)。

次のコマンドを実行してaliyuncliをインストールしaliyuncli (Windowsではsudoを省略)

  1. Python開発ツールをインストールする:

    DebianまたはUbuntu:

    $ sudo apt-get install -y python-dev

    CentOSでは:

    $ sudo yum install python-devel
  2. ECS用のaliyuncliツールとPython SDKをインストールしてください:

    $ sudo pip install -r perfkitbenchmarker/providers/alicloud/requirements.txt

    一部のCentOSバージョンでは、次のものが必要になることがあります:

    $ sudo yum install libffi-devel.x86_64
    $ sudo yum install openssl-devel.x86_64
    $ sudo pip install 'colorama<=0.3.3'

    AliCloudがインストールされているかどうかを確認するには:

    $ aliyuncli --help

    aliyuncli ecsコマンドが準備完了であることを確認します。

    $ aliyuncli ecs help

    「使用法」メッセージが表示された場合は、手順3に従ってください。それ以外の場合は、手順4に進みます。

  3. Ubuntuの特定のバージョンで動作する場合の例外処理。 Pythonのlibパスを取得する: /usr/lib/python2.7/dist-packages

    $ python
    > from distutils.sysconfig import get_python_lib
    > get_python_lib()
    '/usr/lib/python2.7/dist-packages'

    正しいディレクトリにコピーする(Python 2.7.X用):

    $ sudo cp -r /usr/local/lib/python2.7/dist-packages/aliyun* /usr/lib/python2.7/dist-packages/

    もう一度チェック:

    $ aliyuncli ecs help
  4. AliCloudコンソールにアクセスして、アクセスクレデンシャルを作成します。

    • 最初にログインする
    • 「アクセスキー」(右上)をクリックします。
    • 「アクセスキーの作成」をクリックし、「アクセスキーID」と「アクセスキーシークレット」を安全な場所にコピーして保存します。
    • 前の手順でアクセスキーIDとアクセスキーシークレットを使用してCLIを設定する
    $ aliyuncli configure

DigitalOceanの設定と資格情報

  1. https://github.com/digitalocean/doctlの指示に従って、DigitalOcean CLIのdoctlをインストールしhttps://github.com/digitalocean/doctl

  2. doctl認証してdoctl 最も簡単な方法は、 doctl auth loginを実行して指示にdoctlですが、 doctlサイトの任意のオプションが機能します。

RackspaceのCLIと資格情報のインストール

Rackspace Public Cloudと対話するために、PerfKitBenchmarkerはRackCLIを使用します。 RackCLIのインストールと設定の手順は、 https ://developer.rackspace.com/docs/rack-cli/を参照してください。

PerfKit BenchmarkerをRackspaceに対して実行することは非常に簡単です。 Rack CLIがインストールされ、PATHで使用できることを確認してください。オプションで、– --rack_pathフラグを使用してバイナリへのパスを指定してください。

Rackspace UK Public Cloudアカウントの場合、デフォルトのRackCLIプロファイルでない限り、英国アカウント用のプロファイルを作成することをお勧めします。 設定後、–profileフラグを使用して、使用するRackCLIプロファイルを指定します。 詳細はこちらをご覧くださいhttps : //developer.rackspace.com/docs/rack-cli/configuration/#config-file

注:すべての地域ですべてのフレーバーがサポートされているわけではありません。 フレーバーが地域でサポートされているかどうか常に最初に確認してください。

ProfitBricksの設定と資格情報

以下を実行して始めてください:

$ sudo pip install -r perfkitbenchmarker/providers/profitbricks/requirements.txt

PerfKit Benchmarkerは、 Requestsモジュールを使用してProfitBricksのREST APIと対話します。 HTTP基本認証は、APIへのアクセスを承認するために使用されます。 これを次のように設定してください:

ProfitBricksアカウントに関連付けられた電子メールアドレスとパスワードをコロンで区切って含む設定ファイルを作成します。 例:

$ less ~/.config/profitbricks-auth.cfg
email:password

PerfKit Benchmarkerは、REST APIを呼び出す前に資格情報を自動的にbase64でエンコードします。

PerfKit Benchmarkerは、デフォルトでファイル位置~/.config/profitbricks-auth.cfgを使用します。 --profitbricks_configフラグを使用してパスを上書きすることができます。

Dockerベースの雲の画像前提条件

DockerインスタンスはデフォルトでSSHを許可していません。 したがって、SSHサーバーがインストールされるようにDockerイメージを構成することが重要です。 独自のイメージを使用したり、 tools/docker_imagesディレクトリにあるDockerfileに基づいて新しいイメージを作成することができます。この場合はDockerイメージドキュメントを参照してください。

オブジェクト・ストレージ・ベンチマークのための.botoファイルの作成と構成

オブジェクトストレージベンチマークテストを実行するには、適切に構成された~/.botoファイルが必要です。 このgoogle-cloud-sdkがインストールされている必要があります。 それを行うための指示は、 gcloudインストールのセクションにあります。

方法は次のとおりです。

  • ~/.botoファイルを作成する(既に〜/ .botoがある場合は、この手順を省略できます。既存の.botoファイルのバックアップコピーを作成することを検討してください)。

新しい~/.botoファイルを作成するには、次のコマンドを実行して、このコマンドの指示に従います。

$ gsutil config

その結果、ホームディレクトリの下に.botoファイルが作成されます。

.botoファイルを開き、次のフィールドを編集します。

  1. [Credentials]セクションで:

    gs_oauth2_refresh_tokengcloud auth loginステップの一環として設定したgcloud auth login情報ファイル(〜/ .config / gcloud / credentials.db)のrefresh_tokenフィールドと同じに設定しgcloud auth login リフレッシュトークンを表示するには、

    $ strings ~/.config/gcloud/credentials.db.

    aws_access_key_idaws_secret_access_key :これらのテストに使用するAWSアクセスキーに設定するか、既存のAWS認証情報ファイル( ~/.aws/credentials )と同じキーを使用できます。

  2. [GSUtil]セクション:

    default_project_id :まだ設定されていない場合は、このテストに使用するGoogle Cloud StorageプロジェクトIDに設定します。 gsutil configを使用して.botoファイルを生成した場合は、この手順でこの情報を入力するように求められました)。

  3. [OAuth2]セクション:

    client_idclient_secret :これらは、 gcloud auth loginステップの一環として設定されたgcloud auth login情報ファイル( ~/.config/gcloud/credentials.db )の~/.config/gcloud/credentials.dbと同じに設定しgcloud auth login

単一ベンチマークの実行

PerfKit Benchmarkerは、クラウドプロバイダー(GCP、AWS、Azure、DigitalOcean)とSSHで使用できる「マシン」の両方でベンチマークを実行できます。

GCPでの実行例

$ ./pkb.py --project=<GCP project ID> --benchmarks=iperf --machine_type=f1-micro

AWSでの実行例

$ cd PerfKitBenchmarker
$ ./pkb.py --cloud=AWS --benchmarks=iperf --machine_type=t2.micro

Azureでの実行例

$ ./pkb.py --cloud=Azure --machine_type=Standard_A0 --benchmarks=iperf

AliCloudでの実行例

$ ./pkb.py --cloud=AliCloud --machine_type=ecs.s2.large --benchmarks=iperf

DigitalOceanでの実行例

$ ./pkb.py --cloud=DigitalOcean --machine_type=16gb --benchmarks=iperf

OpenStackでの実行例

$ ./pkb.py --cloud=OpenStack --machine_type=m1.medium \
           --openstack_network=private --benchmarks=iperf

Kubernetesでの実行例

$ ./pkb.py --cloud=Kubernetes --benchmarks=iperf --kubectl=/path/to/kubectl --kubeconfig=/path/to/kubeconfig --image=image-with-ssh-server  --ceph_monitors=10.20.30.40:6789,10.20.30.41:6789

メゾスの例

$ ./pkb.py --cloud=Mesos --benchmarks=iperf --marathon_address=localhost:8080 --image=image-with-ssh-server

CloudStackでの実行例

./pkb.py --cloud=CloudStack --benchmarks=ping --cs_network_offering=DefaultNetworkOffering

Rackspaceでの実行例

$ ./pkb.py --cloud=Rackspace --machine_type=general1-2 --benchmarks=iperf

ProfitBricksでの実行例

$ ./pkb.py --cloud=ProfitBricks --machine_type=Small --benchmarks=iperf

Windowsベンチマークの実行方法

上記のようにすべての依存関係をインストールし、Linuxコントローラで実行している場合はsmbclientがシステムにインストールされていることを確認してください:

$ which smbclient
/usr/bin/smbclient

これで、Windowsのベンチマークは--os_type=windows実行でき--os_type=windows Windowsは、Linuxとは異なるベンチマークを持っています。 それらはperfkitbenchmarker/windows_benchmarks/下にあります。 ターゲットVM OSはWindows Server 2012 R2です。

Jujuでベンチマークを実行する方法

Jujuは、サービスオーケストレーションツールであり、クラウド環境全体のモデル化、構成、展開、および管理を迅速に行うことができます。 サポートされているベンチマークは、– --os_type=jujuフラグを指定することにより、余分なユーザー構成を必要とせずにJujuモデルのサービスを自動的に展開します。

$ ./pkb.py --cloud=AWS --os_type=juju --benchmarks=cassandra_stress

ベンチマークのサポート

ベンチマーク/パッケージ作成者は、パッケージ内にJujuInstall()メソッドを実装する必要があります。 このメソッドは、ベンチマーク対象となるサービスをデプロイ、コンフィグレーション、および関連付ける。 FLAGS.os_type == JUJU場合は、他のソフトウェアのインストールと設定をバイパスする必要があります。 実装の例については、 perfkitbenchmarker/linux_packages/cassandra.pyを参照してください。

すべての標準ベンチマークの実行方法

--benchmarksパラメータなしで実行すると、標準セット内のすべてのベンチマークが連続して実行されます。これには数時間かかることがあります(あるいは、– --benchmarks="standard_set"で実行)。 また、 – --cloud=...指定しないと、すべてのベンチマークがGoogle Cloud Platformで実行されます。

名前付きセットですべてのベンチマークを実行する方法

名前付きセットは、ベンチマークディレクトリ内の1つ以上のベンチマークのグループです。 この機能により、クラウドで測定することが重要なことを並行して行うことができ、セット所有者によって定義されます。 たとえば、GoogleSetはGoogleによって管理されていますが、StanfordSetはStanfordによって管理されています。 四半期ごとに1回の会議が開催され、すべてのセットをレビューして、どのベンチマークをstandard_setプロモートするかを決定します。 標準セットはまた、何かを削除すべきかどうかを見るためにレビューされます。 名前付きセット内のすべてのベンチマークを実行するには、ベンチマークパラメータ(たとえば、– --benchmarks="standard_set" )でセット名を指定します。 セットは、個々のベンチマークまたは他の名前付きセットと組み合わせることができます。

有用なグローバルフラグ

PerfKit Benchmarkerを設定する際に使用される一般的なフラグを次に示します。

ノート
--helpmatch=pkb すべてのグローバルフラグを参照
--helpmatch=hpcc hpccベンチマークに関連するすべてのフラグを参照してください。 任意のベンチマーク名を置換して、関連するフラグを表示することができます。
--benchmarks --benchmarks=iperf,pingなど、実行するベンチマークセットまたはベンチマークセットのコンマ区切りリスト。 完全なリストを見るには、. ./pkb.py --help実行して./pkb.py --help
--cloud ベンチマークが実行されるクラウド。 選択肢については下の表を参照してください。
--machine_type 事前プロビジョニングされたマシンが使用されていない場合にプロビジョニングするマシンのタイプ。 ほとんどのクラウドプロバイダは、事前定義されたプロバイダ固有のマシンタイプの名前を受け入れます(たとえば、GCPはGCE n1-standard-8 VMの場合は--machine_type=n1-standard-8をサポートします)。 一部のクラウドプロバイダは、 YAMLコンフィグの対応するVM仕様のmachine_typeプロパティに一致するYAML式をサポートしています(たとえば、GCPは1つのvCPUと4.5のGCEカスタムVMの--machine_type="{cpus: 1, memory: 4.5GiB}" GiBメモリ)。 このフラグによって提供される値は、プロビジョニングされたすべてのマシンに影響を与えます。 1つのベンチマーク実行で異なるロールに異なるマシンタイプをプロビジョニングする場合は、より細かい制御のためにYAMLコンフィグを使用する必要があります。
--zones このフラグを使用すると、デフォルトのゾーンを上書きできます。 下記の表を参照してください。
--data_disk_type 使用するディスクの種類。 名前はプロバイダ固有ですが、以下の表を参照してください。

デフォルトクラウドは ‘GCP’で、– --cloudフラグでオーバーライドします。 各クラウドにはデフォルトのゾーンがあり、これを--zonesフラグで上書きすることができます。このフラグは、対応するクラウドCLIと同じ値をサポートしています。

雲の名前 デフォルトゾーン ノート
GCP us-central1-a
AWS us-east-1a
アズール 米国東部
AliCloud 西アメリカ
DigitalOcean sfo1 ‘メタデータ’(クラウド設定の場合)と ‘private_networking’の機能をサポートするゾーンを使用する必要があります。
OpenStack 新星
CloudStack QC-1
ラックスペース IAD OnMetalマシンタイプはIADゾーンでのみ使用できます
Kubernetes k8s
ProfitBricks オート 追加ゾーン:ZONE_1、ZONE_2、ZONE_3

例:

./pkb.py --cloud=GCP --zones=us-central1-a --benchmarks=iperf,ping

ディスクタイプ名はプロバイダごとに異なりますが、次の表はいくつかの有用なものを要約しています。 (多くのクラウドプロバイダーには、これらのオプションを超えるディスクタイプが増えています)。

雲の名前 ネットワーク接続型SSD ネットワーク接続HDD
GCP pd-ssd pd-standard
AWS gp2 標準
アズール Premium_LRS Standard_LRS
ラックスペース cbs-ssd cbs-sata

また、– --data_disk_type=localは、PKBに別のディスクを割り当てないように指示しますが、VMに付属するものを使用するように指示します。 これは、ローカルSSDに付属するAWSインスタンスタイプや、GCP --gce_num_local_ssdsフラグで--gce_num_local_ssdsです。

インスタンスタイプに複数のディスクが含まれている場合、PKBはルートパーティションを保持していないものを使用します。 具体的には、Azureでは、PKBは常にスクラッチデバイスとして/dev/sdbを使用します。

VMゲストのプロキシ設定。

VMゲストがクラウド環境で直接インターネットにアクセスできない場合は、 pkb.pyフラグを使用してプロキシ設定を構成できます。

単純な設定を行うには、3つのフラグ(すべてのURLは表記法)を使用します。フラグ値は、対応する環境変数と同じ<protocol>://<server>:<port>構文を使用します。たとえば、– --http_proxy=http://proxy.example.com:8080

ノート
--http_proxy ゲストOSおよび一部のPerfkitパッケージのパッケージマネージャに必要
--https_proxy パッケージマネージャーやUbuntuゲスト、githubダウンロードパッケージから必要なもの
--ftp_proxy Needed for some Perfkit packages

Preprovisioned Data

As mentioned above, some benchmarks require preprovisioned data. This section describes how to preprovision this data.

Benchmarks with Preprovisioned Data

Sample Preprovision Benchmark

This benchmark demonstrates the use of preprovisioned data. Create the following file to upload using the command line:

echo "1234567890" > preprovisioned_data.txt

To upload, follow the instructions below with a filename of preprovisioned_data.txt and a benchmark name of sample .

Clouds with Preprovisioned Data

Google Cloud

To preprovision data on Google Cloud, you will need to upload each file to Google Cloud Storage using gsutil. First, you will need to create a storage bucket that is accessible from VMs created in Google Cloud by PKB. Then copy each file to this bucket using the command

gsutil cp <filename> gs://<bucket>/<benchmark-name>/<filename>

To run a benchmark on Google Cloud that uses the preprovisioned data, use the flag --gcp_preprovisioned_data_bucket=<bucket> .

AWS

To preprovision data on AWS, you will need to upload each file to S3 using the AWS CLI. First, you will need to create a storage bucket that is accessible from VMs created in AWS by PKB. Then copy each file to this bucket using the command

aws s3 cp <filename> s3://<bucket>/<benchmark-name>/<filename>

To run a benchmark on AWS that uses the preprovisioned data, use the flag --aws_preprovisioned_data_bucket=<bucket> .

Configurations and Configuration Overrides

Each benchmark now has an independent configuration which is written in YAML. Users may override this default configuration by providing a configuration. This allows for much more complex setups than previously possible, including running benchmarks across clouds.

A benchmark configuration has a somewhat simple structure. It is essentially just a series of nested dictionaries. At the top level, it contains VM groups. VM groups are logical groups of homogenous machines. The VM groups hold both a vm_spec and a disk_spec which contain the parameters needed to create members of that group. Here is an example of an expanded configuration:

hbase_ycsb:
  vm_groups:
    loaders:
      vm_count: 4
      vm_spec:
        GCP:
          machine_type: n1-standard-1
          image: ubuntu-14-04
          zone: us-central1-c
        AWS:
          machine_type: m3.medium
          image: ami-######
          zone: us-east-1a
        # Other clouds here...
      # This specifies the cloud to use for the group. This allows for
      # benchmark configurations that span clouds.
      cloud: AWS
      # No disk_spec here since these are loaders.
    master:
      vm_count: 1
      cloud: GCP
      vm_spec:
        GCP:
          machine_type:
            cpus: 2
            memory: 10.0GiB
          image: ubuntu-14-04
          zone: us-central1-c
        # Other clouds here...
      disk_count: 1
      disk_spec:
        GCP:
          disk_size: 100
          disk_type: standard
          mount_point: /scratch
        # Other clouds here...
    workers:
      vm_count: 4
      cloud: GCP
      vm_spec:
        GCP:
          machine_type: n1-standard-4
          image: ubuntu-14-04
          zone: us-central1-c
        # Other clouds here...
      disk_count: 1
      disk_spec:
        GCP:
          disk_size: 500
          disk_type: remote_ssd
          mount_point: /scratch
        # Other clouds here...

For a complete list of keys for vm_spec s and disk_spec s see virtual_machine.BaseVmSpec and disk.BaseDiskSpec and their derived classes.

User configs are applied on top of the existing default config and can be specified in two ways. The first is by supplying a config file via the --benchmark_config_file flag. The second is by specifying a single setting to override via the --config_override flag.

A user config file only needs to specify the settings which it is intended to override. For example if the only thing you want to do is change the number of VMs for the cluster_boot benchmark, this config is sufficient:

cluster_boot:
  vm_groups:
    default:
      vm_count: 100

You can achieve the same effect by specifying the --config_override flag. The value of the flag should be a path within the YAML (with keys delimited by periods), an equals sign, and finally the new value:

--config_override=cluster_boot.vm_groups.default.vm_count=100

See the section below for how to use static (ie pre-provisioned) machines in your config.

Advanced: How To Run Benchmarks Without Cloud Provisioning (eg, local workstation)

It is possible to run PerfKit Benchmarker without running the Cloud provisioning steps. This is useful if you want to run on a local machine, or have a benchmark like iperf run from an external point to a Cloud VM.

In order to do this you need to make sure:

  • The static (ie not provisioned by PerfKit Benchmarker) machine is ssh’able
  • The user PerfKitBenchmarker will login as has ‘sudo’ access. (*** Note we hope to remove this restriction soon ***)

Next, you will want to create a YAML user config file describing how to connect to the machine as follows:

static_vms:
  - &vm1 # Using the & character creates an anchor that we can
         # reference later by using the same name and a * character.
    ip_address: 170.200.60.23
    user_name: voellm
    ssh_private_key: /home/voellm/perfkitkeys/my_key_file.pem
    zone: Siberia
    disk_specs:
      - mount_point: /data_dir
  • The ip_address is the address where you want benchmarks to run.
  • ssh_private_key is where to find the private ssh key.
  • zone can be anything you want. It is used when publishing results.
  • disk_specs is used by all benchmarks which use disk (ie, fio , bonnie++ , many others).

In the same file, configure any number of benchmarks (in this case just iperf), and reference the static VM as follows:

iperf:
  vm_groups:
    vm_1:
      static_vms:
        - *vm1

I called my file iperf.yaml and used it to run iperf from Siberia to a GCP VM in us-central1-f as follows:

$ ./pkb.py --benchmarks=iperf --machine_type=f1-micro --benchmark_config_file=iperf.yaml --zones=us-central1-f --ip_addresses=EXTERNAL
  • ip_addresses=EXTERNAL tells PerfKit Benchmarker not to use 10.X (ie Internal) machine addresses that all Cloud VMs have. Just use the external IP address.

If a benchmark requires two machines like iperf, you can have two machines in the same YAML file as shown below. This means you can indeed run between two machines and never provision any VMs in the Cloud.

static_vms:
  - &vm1
    ip_address: <ip1>
    user_name: connormccoy
    ssh_private_key: /home/connormccoy/.ssh/google_compute_engine
    internal_ip: 10.240.223.37
    install_packages: false
  - &vm2
    ip_address: <ip2>
    user_name: connormccoy
    ssh_private_key: /home/connormccoy/.ssh/google_compute_engine
    internal_ip: 10.240.234.189
    ssh_port: 2222

iperf:
  vm_groups:
    vm_1:
      static_vms:
        - *vm2
    vm_2:
      static_vms:
        - *vm1

Specifying Flags in Configuration Files

You can now specify flags in configuration files by using the flags key at the top level in a benchmark config. The expected value is a dictionary mapping flag names to their new default values. The flags are only defaults; it’s still possible to override them via the command line. It’s even possible to specify conflicting values of the same flag in different benchmarks:

iperf:
  flags:
    machine_type: n1-standard-2
    zone: us-central1-b
    iperf_sending_thread_count: 2

netperf:
  flags:
    machine_type: n1-standard-8

The new defaults will only apply to the benchmark in which they are specified.

Using Elasticsearch Publisher

PerfKit data can optionally be published to an Elasticsearch server. To enable this, the elasticsearch Python package must be installed.

$ sudo pip install elasticsearch

Note: The elasticsearch Python library and Elasticsearch must have matching major versions.

The following are flags used by the Elasticsearch publisher. At minimum, all that is needed is the --es_uri flag.

ノート
--es_uri The Elasticsearch server address and port (eg localhost:9200)
--es_index The Elasticsearch index name to store documents (default: perfkit)
--es_type The Elasticsearch document type (default: result)

Note: Amazon ElasticSearch service currently does not support transport on port 9200 therefore you must use endpoint with port 80 eg. search-<ID>.es.amazonaws.com:80 and allow your IP address in the cluster.

Using InfluxDB Publisher

No additional packages need to be installed in order to publish Perfkit data to an InfluxDB server.

InfluxDB Publisher takes in the flags for the Influx uri and the Influx DB name. The publisher will default to the pre-set defaults, identified below, if no uri or DB name is set. However, the user is required to at the very least call the --influx_uri flag to publish data to Influx.

ノート デフォルト
--influx_uri The Influx DB address and port. Expects the format hostname:port localhost:8086
--influx_db_name The name of Influx DB database that you wish to publish to or create perfkit

How to Extend PerfKit Benchmarker

First start with the CONTRIBUTING.md file. It has the basics on how to work with PerfKitBenchmarker, and how to submit your pull requests.

In addition to the CONTRIBUTING.md file we have added a lot of comments into the code to make it easy to:

  • Add new benchmarks (eg: --benchmarks=<new benchmark> )
  • Add new package/os type support (eg: --os_type=<new os type> )
  • Add new providers (eg: --cloud=<new provider> )

Even with lots of comments we make to support more detailed documention. You will find the documentation we have on the wiki . Missing documentation you want? Start a page and/or open an issue to get it added.

Integration Testing

If you wish to run unit or integration tests, ensure that you have tox >= 2.0.0 installed.

In addition to regular unit tests, which are run via hooks/check-everything , PerfKit Benchmarker has integration tests, which create actual cloud resources and take time and money to run. For this reason, they will only run when the variable PERFKIT_INTEGRATION is defined in the environment. コマンド

$ tox -e integration

will run the integration tests. The integration tests depend on having installed and configured all of the relevant cloud provider SDKs, and will fail if you have not done so.

計画された改善

Many… please add new requests via GitHub issues.







-GoogleCloudPlatform

執筆者: