YugabyteDBのためのOKEのコスト- 3 -ワークロードを実行します


前のポストは、Oracle雲とデータベースのAをセットアップすることについてでした.
私はデータとネットワークトラフィックを生成したい.使いましょうybdemo いくつかの負荷を実行するコンテナ.

接続


The connect シナリオはYugabyteDBクラスタに接続するだけです.私はyb-tserver-service ロードバランサエンドポイントhikari.properties 接続するyb-tserver-0YBDEMO_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雲でこれのコストを見ることです.