Балансировка токенов в новом бланке Cassandra-Cluster - PullRequest
1 голос
/ 19 октября 2019

Моя установка состоит из 3 узлов Cassandra. каждый узел работает как часть контейнера-докера.

Один начальный узел и два нормальных узла.

Я использую cassandra: последнее, что означает на данный момент версию 3.11.4.

Все узлы работают в одном кластере.

Все узлы работают в одном центре данных.

Я использую следующую настройку в моем docker-compose.yml

- "CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch"
- "CASSANDRA_NUM_TOKENS=8"
- "MAX_HEAP_SIZE=512M"
- "HEAP_NEWSIZE=128M"

Heap-Размеры настолько малы, что он тестирует только начало кластера, а на моем ноутбуке недостаточно оперативной памяти. Разделитель - это по умолчанию Murmur3Partitioner cassandra.

Я запускаю только кластер, без создания пространства ключей или других вещей, проходя через это.

В каждой найденной мной документации естьутверждение о сбалансированном диапазоне токенов и несбалансированном распределении токенов неверно и т. д. и т. д.

Но что такое сбалансированный токен-диапазон?

Когда я запускаю кластер, сначала seedcontainer, сс интервалом в 1 минуту каждый узел подключается и готов.

Кластер исправен и в журнале нет ошибок. В результате docker-compose ps описывает:

         Name                        Command               State                                Ports
----------------------------------------------------------------------------------------------------------------------------------
docker_cassandra-seed_1   docker-entrypoint.sh bash  ...   Up      7000/tcp, 7001/tcp, 7199/tcp, 0.0.0.0:23232->9042/tcp, 9160/tcp
docker_cassandra1_1       docker-entrypoint.sh bash  ...   Up      7000/tcp, 7001/tcp, 7199/tcp, 9042/tcp, 9160/tcp
docker_cassandra2_1       docker-entrypoint.sh bash  ...   Up      7000/tcp, 7001/tcp, 7199/tcp, 9042/tcp, 9160/tcp

Если кластер работает, есть 3 узла с 8 запусками vnode на каждом узле. Это кластерное распределение 24 с всегда 24 диапазонами токенов.

Диапазон токенов в Кассандре составляет от -2 ^ 63 до + 2 ^ 63 - 1 (длина Java). Если я позвоню

docker exec -ti docker_cassandra-seed_1 nodetool ring

, я получу следующий результат:

docker exec -ti docker_cassandra-seed_1 nodetool ring

Datacenter: tc1
==========
Address     Rack        Status State   Load            Owns                Token

172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              -8870864291163548206
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              -8804151848356105327
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              -8578084366820530367
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              -7746741366682664202
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              -7013522326538302096
172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              -6994428155886831685
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              -6650863707982675450
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              -5995004048488281144
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              -5683587085031530885
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              -5274940575732780430
172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              -5184169415607375486
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              -2082614198258325552
172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              -1084866128895283137
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              2495470503021543046
172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              3043280549254813456
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              3058642754102082410
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              3117172086630093502
172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              3405798334726690865
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              3829479365384141235
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              4124513942316551627
172.27.0.2  rack1       Up     Normal  220.44 KiB      55.24%              4807293191442647176
172.27.0.4  rack1       Up     Normal  231.07 KiB      55.89%              4911525338969505185
172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              8068956543491535994
172.27.0.3  rack1       Up     Normal  254.57 KiB      88.87%              8197176123795617738

Это означает, что разница между каждым диапазоном токенов в кольце совершенно иная.

Или, другими словами, идеальный случай для расчета, где ((2^63 * 2) - 1) / (3 * 8) = 768.614.336.404.564.000 токенов на узел в идеальном распределении токенов.

Извините, но здесь у меня есть только быстрое вычисление (вокруг10000s):

-9.223.372.036.854.770.000  Long Min
-8.870.864.291.163.540.000  352.507.745.691.229.000
-8.804.151.848.356.100.000  66.712.442.807.440.400
-8.578.084.366.820.530.000  226.067.481.535.570.000
-7.746.741.366.682.660.000  831.343.000.137.870.000
-7.013.522.326.538.300.000  733.219.040.144.359.000
-6.994.428.155.886.830.000  19.094.170.651.470.800
-6.650.863.707.982.670.000  343.564.447.904.160.000
-5.995.004.048.488.280.000  655.859.659.494.390.000
-5.683.587.085.031.530.000  311.416.963.456.750.000
-5.274.940.575.732.780.000  408.646.509.298.750.000
-5.184.169.415.607.370.000  90.771.160.125.410.300
-2.082.614.198.258.320.000  3.101.555.217.349.050.000
-1.084.866.128.895.280.000  997.748.069.363.040.000
2.495.470.503.021.540.000   3.580.336.631.916.820.000
3.043.280.549.254.810.000   547.810.046.233.270.000
3.058.642.754.102.080.000   15.362.204.847.269.900
3.117.172.086.630.090.000   58.529.332.528.010.200
3.405.798.334.726.690.000   288.626.248.096.600.000
3.829.479.365.384.140.000   423.681.030.657.450.000
4.124.513.942.316.550.000   295.034.576.932.410.000
4.807.293.191.442.640.000   682.779.249.126.090.000
4.911.525.338.969.500.000   104.232.147.526.860.000
8.068.956.543.491.530.000   3.157.431.204.522.030.000
8.197.176.123.795.610.000   128.219.580.304.080.000
9.223.372.036.854.770.000   Long Max

Правый столбец описывает распределение каждого диапазона токенов. И здесь есть большой разрыв между самым большим и самым маленьким диапазоном токенов.

Или немного консолидированный (от середины результата), который является абсолютно неравномерным или несбалансированным или нераспределенным:

-5184169415607375486
-2082614198258325552
-1084866128895283137

После некоторого тестирования я настроил очень простую вещь. Один ПК (с Ubuntu 18.04, Java 1.8.0_201, Cassandra версии 3.6). Установите, оставьте все параметры по умолчанию, включите службу cassandra и посмотрите на распределение токенов.

Вот результат: Распределение токенов в новом кластере

Поэтому мой вопрос: что означает сбалансированный диапазон токенов в кластере Кассандры?

Ответы [ 2 ]

2 голосов
/ 21 октября 2019

Как описано в этой ссылке https://thelastpickle.com/blog/2019/02/21/set-up-a-cluster-with-even-token-distribution.html, похоже, это решение, по крайней мере, для распределения токенов и данных для пространства ключей. Следующие шаги, которые я предпринимаю, чтобы получить сбалансированную систему:

  1. Настройте cassandra.yaml для семенного узла с помощью (для моего тестового примера num_tokens = 8) значения другого параметра по умолчанию
  2. запустите seednode, дождитесь готовности
  3. подключитесь через cqlsh или с помощью программного решения и создайте пространство ключей (для моего теста с коэффициентом репликации = 1).
  4. завершение seed-узла
  5. отредактируйте cassandra.yaml начального узла и закомментируйте / добавьте параметр для allocate_tokens_for_keyspace: [your_keyspace_name_from_step_3]
  6. запуска начального узла и дождитесь готовности узла
  7. отредактируйтеcassandra.yaml для второго узла в кластере выполняет шаг 5. в этом файле и num_token равен num_token начального узла.
  8. запускает второй узел, ожидая, пока он не будет готов
  9. выполните шаги 7-8 для любого другого узла в вашем кластере.

С этим и, например, тестовым запуском с добавлением 2.000.000 датаров в тестовую таблицу в пространстве ключей я вижу следующий результат:

docker exec -ti docker_cassandra-seed_1 nodetool status
Datacenter: tc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  172.30.10.4  36.03 MiB  8            33.3%             1e0d781f-d71f-4704-bcd1-efb5d4caff0e  rack1
UN  172.30.10.2  36.75 MiB  8            33.3%             56287b3c-b0f1-489f-930e-c7b00df896f3  rack1
UN  172.30.10.3  36.03 MiB  8            33.3%             943acc5f-7257-414a-b36c-c06dcb53e67d  rack1

Дажеtokendistribution лучше, чем раньше:

172.30.10.2                         6.148.914.691.236.510.000
172.30.10.3                         6.148.914.691.236.520.000
172.30.10.4                         5.981.980.531.853.070.000

На данный момент есть некоторые разъяснения по поводу проблемы с неравномерным распределением, поэтому еще раз спасибо Крис Лохфинк за ссылку с решением.

0 голосов
/ 21 октября 2019

Я тестирую немного по вышеописанному сценарию. Мой тестовый кластер состоит из 5 узлов (1 начальное число, 4 нормальных узла).

Первые 5 шагов выше остаются действительными:

  1. Настройте cassandra.yaml для начального узла с помощью (для моего тестового примера num_tokens = 8) пусть другой параметр по умолчанию
  2. запустит начальный узел, дождется готовности
  3. подключится через cqlsh или с помощью программного решения и создаст пространство ключей (для моего тестового случая с репликацией-фактор = 1).
  4. выключите начальный узел, отредактируйте cassandra.yaml начального узла и закомментируйте / добавьте параметр для allocate_tokens_for_keyspace: [your_keyspace_name_from_step_3]

  5. запуска семенного узла-узел и подождите, пока узел не будет готов

Затем вы можете запустить все остальные узлы (в моем случае 4) одновременно (или с задержкой в ​​1 минуту между запусками каждого узла). ), но автоматизировано. Важно то, что все узлы имеют набор allocate_tokens_for_keyspace: [your_keyspace....].

После того, как все узлы подняты и заполнены 1.000.000 строк, существует равномерный баланс в 20%.

ТоСценарий облегчает жизнь, если вы запускаете кластер с большим количеством узлов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...