YugabyteDBのためのOKEのコスト- 3 -ワークロードを実行します
29488 ワード
前のポストは、Oracle雲とデータベースのAをセットアップすることについてでした.
私はデータとネットワークトラフィックを生成したい.使いましょうybdemo いくつかの負荷を実行するコンテナ.
The
いくつかの読み込みと書き込みを行うには、
私は、列を挿入するシナリオを持っています.
スループットをチェックしたいときは
Kubernetes上の分散データベースの実行の美しさは、状態セットのスケーリングが十分であるということです.yugabytedbは、接続、処理、およびデータを再調整します.
ステートセットには3つのポッドがあります.
ポッドは、アンチアフィニティプロパティのおかげで、労働者に配布されます.労働者はノードプールによって可用性ノードに分配される.配置定義では、この情報を3つの可用性ドメインを含むように、タブレットリーダーとフォロワーを再調整するyugabytedbにこの情報を与えます.
私の目標は、あらゆる種類のトラフィックを生成することです.私は
YugabyteDBの高い可用性はインフラストラクチャの失敗だけではない.我々は、アプリケーションを中断せずに、ローリングファッションでノードを再起動することができます.以下に例を示します.
すべてのノードは、接続、データ、および読み込みと書き込みを行うと、ビジー状態です.
ヘルムチャートのインストールでは、tserver - podsの4 gbbytesメモリを定義しました.
これは、アップデートのローリングで簡単です.
コンテナは新しい値で再起動します.
これらのすべてのデモコンテナを終了したい場合は、再度起動してください.
私は、この実行を数日後にコストを見るようにしています.これは次のポストにあります.クラスタを削除する場合は、リソースを削除する必要があります.彼らがノードプールの一部であるように、計算インスタンスは自動的に終了されます、しかし、あなたがそれらを取り外さないならば、ボリュームと荷貸し手はとどまります.インストールの終わりに表示されたインストールノートには、指示があります.
私はこの実行を許可し、より多くの労働者を追加します.私の目標は、次のポストのために、Oracle雲でこれのコストを見ることです.
私はデータとネットワークトラフィックを生成したい.使いましょうybdemo いくつかの負荷を実行するコンテナ.
接続
The
connect
シナリオはYugabyteDBクラスタに接続するだけです.私はyb-tserver-service
ロードバランサエンドポイントhikari.properties
接続するyb-tserver-0
とYBDEMO_DOMAIN
Kubernetesドメインを追加します.これは接続を分配します、しかし、それに加えて、私はyugabytedbクラスタ意識のJDBCドライバーを使用しています、そして、接続はすべてのポッドに釣り合っています.各アプリケーションサーバをローカルに接続したいなら、接続文字列の特定のゾーンを指定できます.dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo run ybdemo1 \
--env="YBDEMO_DOMAIN=yb-tservers" --image=pachot/ybdemo \
--env="YBDEMO_CASE=connect" --env="YBDEMO_THREADS=10"
pod/ybdemo1 created
デモプログラムは、各スレッドが接続されている場所を示します.dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo logs ybdemo1 | tail
Thread-20 1002 ms: 06-APR 09:46:10 pid: 2618 host: 10.244.0.132
Thread-26 1003 ms: 06-APR 09:46:10 pid: 2652 host: 10.244.0.5
Thread-17 1002 ms: 06-APR 09:46:10 pid: 2610 host: 10.244.0.5
Thread-8 1003 ms: 06-APR 09:46:10 pid: 2561 host: 10.244.0.132
Thread-2 1002 ms: 06-APR 09:46:10 pid: 2546 host: 10.244.0.5
Thread-29 1002 ms: 06-APR 09:46:10 pid: 2659 host: 10.244.0.132
Thread-5 1002 ms: 06-APR 09:46:10 pid: 2647 host: 10.244.0.132
Thread-23 1004 ms: 06-APR 09:46:10 pid: 2629 host: 10.244.1.4
Thread-11 1002 ms: 06-APR 09:46:10 pid: 2595 host: 10.244.0.132
Thread-14 1004 ms: 06-APR 09:46:10 pid: 2607 host: 10.244.1.4
私は現在3台のポッドを持っています、そして、私は3つのIPアドレスを見ます.ホスト名を確認するのは簡単です.dev@cloudshell:~ (uk-london-1)$
kubectl get pods -n yb-demo
-o custom-columns="IP:.status.podIP,NAMESPACE:.metadata.namespace,NAME:.metadata.name"
IP NAMESPACE NAME
10.244.0.4 yb-demo yb-master-0
10.244.1.3 yb-demo yb-master-1
10.244.0.131 yb-demo yb-master-2
10.244.0.132 yb-demo yb-tserver-0
10.244.1.4 yb-demo yb-tserver-1
10.244.0.5 yb-demo yb-tserver-2
10.244.0.133 yb-demo ybdemo1
この構成で、1つのloadbalancerは、私の3つの利用可能な領域の向こう側にどんなpodにでも向けます.このロードバランサはOCIコンソールから見えますが、OKEで管理されます.クリエイト
いくつかの読み込みと書き込みを行うには、
init scenario
:dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo run ybdemo0 --image=pachot/ybdemo \
--restart=Never --env="YBDEMO_DOMAIN=yb-tservers" \
--env="YBDEMO_CASE=init" --env="YBDEMO_THREADS=1"
pod/ybdemo0 created
ログは実行されたコマンドを示します:dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo logs ybdemo0
drop table if exists demo;
ysqlsh:/dev/stdin:1: NOTICE: table "demo" does not exist, skipping
DROP TABLE
create table if not exists demo(id bigint generated by default as identity, ts timestamptz default clock_timestamp(), message text, u bigint default 0, i timestamptz default clock_timestamp(), primary key(id hash));
CREATE TABLE
insert into demo(message) select format('Message #%s',generate_series(1,1000));
INSERT 0 1000
select format('All good :) with %s rows in "demo" table ',count(*)) from demo;
format
---------------------------------------------
All good :) with 1000 rows in "demo" table
(1 row)
タブレットをチェックしたい場合は、コンソールを表示します.インサート
私は、列を挿入するシナリオを持っています.
dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo run ybdemo2 --image=pachot/ybdemo \
--env="YBDEMO_DOMAIN=yb-tservers" \
--env="YBDEMO_CASE=insert" --env="YBDEMO_THREADS=300"
pod/ybdemo2 created
kubectl -n yb-demo run ybdemo3 --image=pachot/ybdemo \
--env="YBDEMO_DOMAIN=yb-tservers" \
--env="YBDEMO_CASE=insert" --env="YBDEMO_THREADS=300"
pod/ybdemo3 created
kubectl -n yb-demo run ybdemo4 --image=pachot/ybdemo \
--env="YBDEMO_DOMAIN=yb-tservers" \
--env="YBDEMO_CASE=insert" --env="YBDEMO_THREADS=300"
pod/ybdemo4 created
ログは挿入され、挿入されたポッドをトレースします.これは、YugabyteDBセッションのためのPostgreSQLバックエンドプロセスですdev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo logs ybdemo2 | tail
Thread-40 9 ms: {"id":91458,"ts":"2022-04-06T09:56:04.397588+00:00","message":"inserted when connected to 10.244.0.5","u":0,"i":"2022-04-06T09:56:04.397596+00:00"}
Thread-45 6 ms: {"id":88799,"ts":"2022-04-06T09:56:04.40014+00:00","message":"inserted when connected to 10.244.0.132","u":0,"i":"2022-04-06T09:56:04.400182+00:00"}
Thread-18 10 ms: {"id":89492,"ts":"2022-04-06T09:56:04.396587+00:00","message":"inserted when connected to 10.244.0.132","u":0,"i":"2022-04-06T09:56:04.396594+00:00"}
Thread-10 7 ms: {"id":88991,"ts":"2022-04-06T09:56:04.39952+00:00","message":"inserted when connected to 10.244.0.132","u":0,"i":"2022-04-06T09:56:04.399529+00:00"}
Thread-33 8 ms: {"id":92627,"ts":"2022-04-06T09:56:04.398597+00:00","message":"inserted when connected to 10.244.0.5","u":0,"i":"2022-04-06T09:56:04.398604+00:00"}
Thread-27 8 ms: {"id":90371,"ts":"2022-04-06T09:56:04.400254+00:00","message":"inserted when connected to 10.244.0.132","u":0,"i":"2022-04-06T09:56:04.400263+00:00"}
Thread-48 8 ms: {"id":91357,"ts":"2022-04-06T09:56:04.40041+00:00","message":"inserted when connected to 10.244.0.132","u":0,"i":"2022-04-06T09:56:04.400418+00:00"}
Thread-5 8 ms: {"id":92821,"ts":"2022-04-06T09:56:04.40054+00:00","message":"inserted when connected to 10.244.0.132","u":0,"i":"2022-04-06T09:56:04.400549+00:00"}
Thread-32 7 ms: {"id":93503,"ts":"2022-04-06T09:56:04.403381+00:00","message":"inserted when connected to 10.244.0.5","u":0,"i":"2022-04-06T09:56:04.403389+00:00"}
Thread-37 7 ms: {"id":92918,"ts":"2022-04-06T09:56:04.403144+00:00","message":"inserted when connected to 10.244.0.5","u":0,"i":"2022-04-06T09:56:04.403153+00:00"}
カウント
スループットをチェックしたいときは
count
シナリオdev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo run ybdemo5 --image=pachot/ybdemo --env="YBDEMO_DOMAIN=yb-tservers" \
--env="YBDEMO_CASE=count" --env="YBDEMO_THREADS=1"
pod/ybdemo5 created
タイムスタンプの範囲スキャンインデックスを持っている方が良いcount
最後の分の照会フィルタyugabyte=# create index demots on demo(ts asc);
CREATE INDEX
/*+ IndexOnlyScan(demo demots) */ select format('Rows inserted in the last minute: %s',to_char(count(*),'999999999')) from demo where ts > clock_timestamp() - interval '1 minute';
出力は1分あたりの挿入数を示します.dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo logs -f
ybdemo5--------------------------------------------------
----- YBDemo -- Franck Pachot -- 2022-02-06 ------
----- https://github.com/FranckPachot/ybdemo -----
--------------------------------------------------
63 [main] INFO com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Starting...
1672 [main] INFO com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Start completed.
--------------------------------------------------
sql executed in each new connection init:
--------------------------------------------------
prepare ybdemo(int) as select
format('%8s pid: %8s %25s %30s %12s',to_char(now(),'DD-MON HH24:MI:SS')
,pg_backend_pid(),' host: '||lpad(host,16),cloud||'.'||region||'.'||zone,node_type)
as yb_server, pg_sleep($1/1000)
from (select replace(current_setting('listen_addresses'),'0.0.0.0',host(inet_server_addr())::text) as host) as server
natural left join (select host,node_type,cloud,region,zone from yb_servers()) servers
--------------------------------------------------
input lines will start a thread to execute in loop
--------------------------------------------------
Starting a thread for select format('Rows inserted in the last minute: %s',to_char(count(*),'999999999')) from demo where ts > clock_timestamp() - interval '1 minute'
Thread-1 7894 ms: Rows inserted in the last minute: 60744
Thread-1 6379 ms: Rows inserted in the last minute: 61462
Thread-1 7890 ms: Rows inserted in the last minute: 60374
Thread-1 7312 ms: Rows inserted in the last minute: 60264
Thread-1 7394 ms: Rows inserted in the last minute: 60091
Thread-1 10202 ms: Rows inserted in the last minute: 56947
スケールアウト
Kubernetes上の分散データベースの実行の美しさは、状態セットのスケーリングが十分であるということです.yugabytedbは、接続、処理、およびデータを再調整します.
ステートセットには3つのポッドがあります.
dev@cloudshell:~ (uk-london-1)$
kubectl get statefulsets -n yb-demo -o wide
NAME READY AGE CONTAINERS IMAGES
yb-master 3/3 66m yb-master,yb-cleanup yugabytedb/yugabyte:2.13.0.0-b42,yugabytedb/yugabyte:2.13.0.0-b42
yb-tserver 3/3 66m yb-tserver,yb-cleanup yugabytedb/yugabyte:2.13.0.0-b42,yugabytedb/yugabyte:2.13.0.0-b42
これは十分ですyb-master
, 制御面yb-tserver
スケーリングから恩恵を受ける.彼らを9のポッドに持ってきましょう:dev@cloudshell:~ (uk-london-1)$
kubectl scale -n yb-demo statefulset yb-tserver --replicas=9
statefulset.apps/yb-tserver scaled
チェック(数分後)dev@cloudshell:~ (uk-london-1)$
kubectl get statefulsets -n yb-demo -o wide
NAME READY AGE CONTAINERS IMAGES
yb-master 3/3 67m yb-master,yb-cleanup yugabytedb/yugabyte:2.13.0.0-b42,yugabytedb/yugabyte:2.13.0.0-b42
yb-tserver 6/9 67m yb-tserver,yb-cleanup yugabytedb/yugabyte:2.13.0.0-b42,yugabytedb/yugabyte:2.13.0.0-b42
yugabytedbデータベースを自動的に新しいポッドを検出し、負荷を再バランス:ポッドは、アンチアフィニティプロパティのおかげで、労働者に配布されます.労働者はノードプールによって可用性ノードに分配される.配置定義では、この情報を3つの可用性ドメインを含むように、タブレットリーダーとフォロワーを再調整するyugabytedbにこの情報を与えます.
読み取り
私の目標は、あらゆる種類のトラフィックを生成することです.私は
read
小さな作業セット内でランダムに行を問い合わせるシナリオdev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo run ybdemo6 --image=pachot/ybdemo --env="YBDEMO_DOMAIN=yb-tservers" \
--env="YBDEMO_CASE=read" --env="YBDEMO_THREADS=100"
pod/ybdemo6 created
ローリング再開
YugabyteDBの高い可用性はインフラストラクチャの失敗だけではない.我々は、アプリケーションを中断せずに、ローリングファッションでノードを再起動することができます.以下に例を示します.
dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo rollout restart sts yb-tserver --wait
statefulset.apps/yb-tserver restarted
データベース側では何もすることがありません.yugabytedbは失敗するノードを検出し、quorumはまだそこにアプリケーションが続けている.再スタートするノードのリーダーを持っていた錠剤は、リーダーになっている彼らの信者の1人を持っています.このノードに接続されたスレッドは接続プールとスマートドライバのおかげで再接続します.ポッドが再起動すると、ノードは同じボリュームを取得し、そこにフォロワーを同期させるために他のタブレットピアから欠落した変更をプルします.その後、いくつかの負荷をバランスするリーダーに選出されます.すべてのノードは、接続、データ、および読み込みと書き込みを行うと、ビジー状態です.
最新圧延
ヘルムチャートのインストールでは、tserver - podsの4 gbbytesメモリを定義しました.
resource:
master:
requests:
cpu: 2
memory: 2Gi
limits:
cpu: 2
memory: 2Gi
tserver:
requests:
cpu: 2
memory: 4Gi
limits:
cpu: 2
memory: 4Gi
私は労働者のVMを与えられた私は32 GBにそれを増加したい.これは、アップデートのローリングで簡単です.
dev@cloudshell:~ (uk-london-1)$
kubectl -n yb-demo patch statefulset yb-tserver --type='json' -p='[
{"op": "replace",
"path": "/spec/template/spec/containers/0/resources/limits/memory",
"value":"32Gi"},
{"op": "replace",
"path": "/spec/template/spec/containers/0/resources/requests/memory",
"value":"16Gi"}
]'
これはコンテナーのためのより多くのメモリを可能にします.これは接続(PostgreSQLバックエンド)で利用可能です、しかし、私もTServerがより多くを使用したいです、そして、これはyb-tserver
コマンドライン--memory_limit_hard_bytes=3649044480
ヘルムテンプレートの中から--memory_limit_hard_bytes={{ template "yugabyte.memory_hard_limit" $root.Values.resource.tserver }}
私はそれを16 GBに変更しますkubectl edit sts yb-tserver -n yb-demo
:コンテナは新しい値で再起動します.
dev@cloudshell:~ (uk-london-1)$
kubectl edit sts yb-tserver -n yb-demo
statefulset.apps/yb-tserver edited
dev@cloudshell:~ (uk-london-1)$
kubectl get pods -n yb-demo -w
NAME READY STATUS RESTARTS AGE
yb-master-0 2/2 Running 0 27h
yb-master-1 2/2 Running 0 27h
yb-master-2 2/2 Running 0 27h
yb-tserver-0 2/2 Running 0 36m
yb-tserver-1 2/2 Running 0 36m
yb-tserver-2 2/2 Running 0 37m
yb-tserver-3 2/2 Running 0 38m
yb-tserver-4 2/2 Running 0 38m
yb-tserver-5 2/2 Running 0 39m
yb-tserver-6 2/2 Running 0 40m
yb-tserver-7 2/2 Running 0 40m
yb-tserver-8 0/2 ContainerCreating 0 2s
ybdemo2 1/1 Running 58 (4m14s ago) 26h
...
一旦実行されたら、ここではTserver memtrackersからメモリをチェックします.dev@cloudshell:~ (uk-london-1)$
for i in yb-tserver-{0..8}
do
kubectl -n yb-demo exec -it $i -c yb-tserver -- \
curl http://$i:9000/mem-trackers?raw |
awk '{gsub(/<[/]?td>/," ")}/ (root) /{print n,$0}' n=$i
done
yb-tserver-0 root 6.38G 6.42G 13.59G
yb-tserver-1 root 6.84G 6.86G 13.59G
yb-tserver-2 root 7.60G 7.63G 13.59G
yb-tserver-3 root 7.34G 7.37G 13.59G
yb-tserver-5 root 1.13G 1.13G 13.59G
yb-tserver-6 root 2.08G 2.24G 13.59G
yb-tserver-7 root 1.75G 2.17G 13.59G
yb-tserver-8 root 1.88G 2.24G 13.59G
もちろん、ステータスセットを編集している間、リソース仕様を変更することができて、1回のリスタートだけを持つことができました.デモを終了する
これらのすべてのデモコンテナを終了したい場合は、再度起動してください.
dev@cloudshell:~ (uk-london-1)$
kubectl get pods \
-o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name" \
-A | grep ybdemo | while read namespace name
do
kubectl -n "$namespace" delete pod --force "$name"
done
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "ybdemo1" force deleted
アンインストールする
私は、この実行を数日後にコストを見るようにしています.これは次のポストにあります.クラスタを削除する場合は、リソースを削除する必要があります.彼らがノードプールの一部であるように、計算インスタンスは自動的に終了されます、しかし、あなたがそれらを取り外さないならば、ボリュームと荷貸し手はとどまります.インストールの終わりに表示されたインストールノートには、指示があります.
私はこの実行を許可し、より多くの労働者を追加します.私の目標は、次のポストのために、Oracle雲でこれのコストを見ることです.
Reference
この問題について(YugabyteDBのためのOKEのコスト- 3 -ワークロードを実行します), 我々は、より多くの情報をここで見つけました https://dev.to/franckpachot/the-cost-of-oke-for-yugabytedb-3-run-a-workload-pp7テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol