Big Data

     K3s за замовченням використовує traefik ingress controller який виконує свою функцію бездоганно, має свій web dashboard  і багато інших хороших речей ...але, в багатьох ситуаціях, коли необхідно відносно швидко підняти й протестувати необхідний сервіс, приходиться констатувати факт, що helm charts мають приклади для конфігурування nginx  ingress controller й не мають аналогічних прикладів для traefik, що значно ускладнює й сповільнює процес прототипування й тестування нових інструментів.     Заміна  Traefik на Nginx ingress controller може стати можливим рішенням даної ситуації.  Для початку необхідно видалити Traefik helm chart: kubectl -n kube-system delete helmcharts.helm.cattle.io traefik Зупиняємо k3s: sudo service k3s stop далі необхідно в файлі " /etc/systemd/system/k3s.service " добавити " –no-deploy traefik " в рядок " ExecStart ": ExecStart=/usr/local/bin/k3s \ server \ --disable traefik \ далі перезагружаємо сервіс та видаляємо ман

K3s  полегшенна й більш повноцінна (в порівняні з minikube ) версія  kubernetes для локального середовища розробки та тестування.   Все встановлення заключається в скачуванні бінарного файла: curl -sfL https://get.k3s.io | sh - Helm за замовченням шукає файл конфігурації в  " $HOME /.kube/config"   тоді як K3s розмістив його тут " /etc/rancher/k3s/k3s.yaml" . Необхідно переконатись що поточний користувач має права доступу до цього файлу а також скопіювати або злінкувати конфіг файл . Приклад присвоювання прав доступа до конфігураційного файлу: sudo chown $(whoami):$(id -g -n) /etc/rancher/k3s/k3s.yaml Приклад копіювання: mkdir $HOME/.kube sudo cp /etc/rancher/k3s/k3s.yaml $HOME/.kube/config sudo chmod 644 $HOME/.kube/config Приклад лінкування: ln -s /etc/rancher/k3s/k3s.yaml $HOME/.kube/config Встановлюєм "local-path-storage": kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml kubectl g

   При запуске задач с помощью Apache Oozie часто возникает ошибка: java.lang.ClassNotFoundException: org.apache.hadoop.hbase.ipc.RpcControllerFactory   Суть в том, что по умолчанию у Вас не все библиотеки подключены в ShareLib. После настройки и запуска job-a может возникнуть ошибка "java.lang.ClassNotFoundException", которая и говорит нам, что Oozie попросту не видит данную реализацию в подключённых jar-никах в директории ShareLib.    Вам нужно указать Oozie где в HDFS лежат нужные jar файлы. Для этого создаём директорию в HDFS где будут лежать наши jar файлы: hadoop fs -mkdir /user/oozie/custom_share   Далее закачиваем jar в hdfs эту директорию: hadoop fs -put target/HBase-1.0-SNAPSHOT-jar-with-dependencies.jar hdfs:///user/oozie/custom_share/ Далее нужно в файле job.properties указать эту директорию в переменной  oozie.libpath oozie.libpath=/user/oozie/custom_share Полезные ссылки: Add a common HBase lib in hdfs on cluster start How to Set up Oozi

   Oozie - это система для планирования выполнения повторяющихся задач в экосистеме Hadoop. В этой системе можно сконфигурировать цыкл задач написаных на Java,  Apache Hive, Apache Pig и Apache Sqoop, Apache Spark, UNIX Shell  и т.д. Oozie задачи могут быть быть сконфигурированы для регулярного выполнения или для выполнения при возникновении некоторого события. Задачи, которые должны быть запущены периодично - это задачи типа  Oozie coordinator. Задачи, которые должны быть запущены последовательно - это задачи типа Oozie Workflow. Задачи, которые вмещают в себе и задачи типа  Oozie coordinator и типа   Oozie Workflow, называются задачами типа Oozie Bundle и предоставляют возможность мониторить и координировать жизненный цикл всех типов задач в виде одного целого. Oozie Coordinators    Oozie coordinator планирует задачу на основе время начала и частоты выполнения задачи и также когда все необходимые входящие данные доступны. Если же входящие данные не доступны, то запуск т

В дистрибутиве от Cloudera напрямую работать с supervisor не получится. Дело в том, что саму службу они скрыли и она не доступна по стандартной команде "service supervisord" а файли настроек не находятся на своем привычном месте "/etc/supervisor/supervisord.conf". Так что же делать, если у Вас возникла например необходимость настроить стабильную работу  REST API для работы c Spark-ом на основе Livy Spark Server  ? Проблема усложняется тем, что на данный момент дистрибутив Cloudera официально не поддерживает эту службу и потому нужно самому собрать и запустить Livy сервер из исходников. После установки самого Livy сервера возникает необходимость  повысить отказоустойчивость путём мониторинга и автоматического перезапуска службы в случае падения. Настройки supervisor-a в случае собранного кластера на основе дистрибутива от Cloudera находится по этому адресу: "/var/run/cloudera-scm-agent/supervisor/include/" Создадим в этой директории файл "li

Эта ошибка возникает потому, что Solr берёт фактор репликации(replication factor) с конфигов hdfs только для индекса. Для Tlog нужно фактор репликации устанавливать в локальном конфигурационном файле /var/lib/solr/solr_configs/conf/solrconfig.xml или /var/lib/solr_configs/conf/solrconfig.xml: <updatelog> <int name="tlogDfsReplication">2</int> ... </updatelog>