Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料
Kafka・Storm・ZooKeeperの認証と認可について #kafkajp
Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料
1台のサーバーでZooKeeperアンサンブル、Kafkaクラスターを構成 - Qiita
概要 1台のサーバー上でZooKeeperアンサンブルとKafkaクラスターを構成したときのメモです。 ZooKeeperはKafkaに同梱のものを使用しました。 構成図は以下になります。 サーバーの環境情報は以下の通りです。 CentOS V7.4 OpenJDK V1.8 Kafka V1.1.0 構成手順 ZooKeeperの設定ファイルの作成 今回ZooKeeperは3インスタンスでアンサンブルを構成するため、以下の3つのプロパティーファイルを用意します。 ZooKeeper#1用プロパティーファイル tickTime=2000 initLimit=5 syncLimit=2 dataDir=/var/lib/zookeeper1 clientPort=2181 server.1=localhost:2888:3888 server.2=localhost:2889:3889 se
docker-compose で zookeeper のクラスタのフェイルオーバーを試す - Qiita
docker-compose で zookeeper のクラスタを立ち上げて動作確認する - Qiita の続き。今度はフェイルオーバーを試してみる。 leader/follower の確認 まず、クラスタ内のどのコンテナが leader でどのコンテナが follower なのかを確認できるようしておく。 基本的には、各プロセスが LISTEN してる TCP ポートに srvr という文字列を送ると、そのプロセスの Mode を取得することができる。 $ echo srvr | docker exec -i zookeeper_zoo1_1 nc localhost 2181 Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT Latency min/avg/max: 0/2/35 Received: 73 S
docker-compose で zookeeper のクラスタを立ち上げて動作確認する - Qiita
タイトルの通り、docker で zookeeper のクラスタ (= アンサンブル) を立ち上げて動作確認してみた。 クラスタ立ち上げ 作業ディレクトリを作って docker-compose.yml を作成する。 version: '2' services: zoo1: image: zookeeper restart: always ports: - 2181:2181 environment: ZOO_MY_ID: 1 ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888 zoo2: image: zookeeper restart: always ports: - 2182:2181 environment: ZOO_MY_ID: 2 ZOO_SERVERS: ser
ビッグデータを支える技術 - Qiita
Hadoop 大規模な分散処理を支えるJavaフレームワーク HadoopはGoogleのMapReduce、GFS(Google File System)の技術をベースとして作られた HadoopではMapReduceはそのまま「MapReduce(Hadoop/MapReduce)」、GFSは「HDFS(Hadoop Distributed File System)」という名前でそれぞれ開発・公開されている MapReduce データを「Map処理」、「Reduce処理」の2つの処理で処理するモデル 以下、Hadoop/MapReduceの機能 複数のマシン上にデータとデータを処理するためのプログラムモジュールを配置し、プログラムを並列実行する 複数マシン上で分散実行される処理の順序や優先度の制御 障害時の自動リカバリ 処理状況のステータス管理や監視機能 処理全体のパフォーマンスを向上
Cronの置き換え『Chronos』を試してみる - tsunokawaのはてなダイアリー
やりたいこと 物理、仮想含め数百台のサーバーを管理しているので、 cronを一括管理したい cronジョブの負荷を分散したい cronの結果を可視化(成功or失敗) Dockerコンテナのcronを外出ししたい Dockerコンテナが作成または削除される度にcron登録・削除をAPIで行いたい これらを実現したいと思っていました。 そこで『Chronos』です！ 結論から言うとChronosを使ってこれらを実現することができました。 Chronosとは そこでChronosって何？という話しになりますが、 Cronの置き換えを想定したジョブスケジューラです。 airbnb/chronos · GitHub Mesos上で動くので登録されたジョブをいい感じに分散して実行してくれます。 図にするとこのような感じだと思います。 検証環境 本エントリで例としてIPアドレスやmesos-master
「ZooKeeperによる分散システム管理」を読もう、という話 - たごもりすメモ
Zookeeperは現代の分散システムに不可欠なミドルウェアで、メタデータの管理、更新通知、リーダー選出といった問題を解決する。自分でZookeeper APIを叩く人は少ないかもしれないが、今やHadoop Namenode HA*1もYARN ResourceManager HAもHBaseもZookeeperを要求する。とにかく使う必要がある、という人は今や多いのではないだろうか。 こういったソフトウェアが何故必要なのか、どういった役割を持つのかについて、明快な回答を返せる人はあまり多くないのではないだろうか。Zookeeperは必要性を喧伝され、あちこちで使われ、しかしいまだに、何台で動かす必要があるのか、どのように運用されなければならないのか、ということをまとめて学べる資料などは多くない。 ということで、この本を読もう。 「2.2.1 Zookeeperのクォラム」。個人的には、
分散環境でどうなるかはテストしてみないとわからない - ワザノバ | wazanova
https://www.youtube.com/watch?v=QdkS6ZjeR7Q 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Kyle Kingsburyは、「クラウドにおいてもネットワークパーティションは起こりうるゆえに、DBなどのプロダクトはマニュアルやマーケティング資料で説明している仕様 & パフォーマンスを、分散環境では必ずしもだせない。」というテーマでの検証結果を公表しているブログのシリーズと、ストレス下での計測ツールJepsenで知られています。ここ1年半ほどで、 PostgreSQL / Redis / MongoDB / Riak / Zookeeper / NuoDB / Kafka / Cassandra / Redis / RabbitMQ / etcd / Consu
Coordination Service(ZooKeeper，etcd ，consul) の比較
概要 最近，consul，etcd，ZooKeeper といった，いわゆる Coordination Service(この名前は ZooKeeper の論文から拝借した)の実装が頻繁に行われている．本記事では，開発が盛んな背景を踏まえた上で，オープンソース実装の Coordination Service の比較を行う． Chubby から現在まで Paxos が Google の手によって Chubby という形で実用化された後，故障検出+分散合意アルゴリズムを用いた高可用KVSという組み合わせによる Coordination Service のオープンソース実装がいくつが出てきた．そのはしりが ZooKeeper である．ZooKeeper は Hadoop ファミリではデファクトスタンダードの Coordination Service であり，Hadoop を初めとして HBase，M
HBaseとZookeeperの設定 - Just sleepy
完全分散モードによるHBaseとZookeeperに関する設定メモです。Hadoopについては以前のブログの内容に従ってインストールされていることが前提です。 今回利用したバージョンはhbase-0.94.11とzookeeper-3.4.5です。なお、hbase-0.94.11のデフォルトのHadoopバージョンは1.0.4で前回は1.1.2を設定する方法を紹介しましたが設定方法は同じです。 なお、今回紹介する方法はhbaseにzookeeperを管理させず、zookeeperノードを単体で起動する方法を紹介します。zookeeperは奇数台必要となります。 [ ]はそれぞれの環境で任意の設定値に読み替えてください。 ■Zookeeperの設定 rootユーザでzookeeperを解凍し、ディレクトリのオーナーなどの設定を行います。 su - cd /usr/local tar -zxv
管理が困難―分散処理の常識はZooKeeperで変わる
管理が困難―分散処理の常識はZooKeeperで変わる：ビッグデータ処理の常識をJavaで身につける（8）（1/3 ページ） Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク／ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載 分散処理の課題が「管理」なのは常識 複数の計算機上で動作（分散）するアプリケーション、ソフトウェアが多く存在します。分散ソフトウェアは複数の計算機で動作することで大量のデータを扱えたり、高負荷な状況に対処します。本稿では、複数の計算機（クラスタ）で動作する各サーバを「インスタンス」と呼びます。 本連載で紹介した分散Key-Valueデータベースである「HBase」は複数の計算機で動作する代表的なソフトウェアです。両ソフトウェアはともに「Apache ZooKeeper」（以下、Z
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ZooKeeper入門を読んだ • masu-mi's blog(dirty pages)
Comparing ZooKeeper and Consul
ZKFC のドキュメントまとめ - /var/log/hadoop.log