前書き
OrientDBは、グラフおよびドキュメントデータベースをサポートするマルチモデルNoSQLデータベースです。 これはJavaアプリケーションであり、任意のオペレーティングシステムで実行できます。 また、完全にACIDであり、マルチマスタークラスタリングとレプリケーションのサポートに不満があり、簡単な水平スケーリングが可能です。
ただし、OrientDBの「クラスター」という言葉は、2つの異なる概念を指す場合があります。
-
OrientDBを実行しているサーバーであるOrientDBnodesのクラスターを持つことができます。 これは、1つのサーバーで複数のOrientDBインスタンスを実行できるため、少なくとも1つの物理(またはクラウド)サーバーを使用することを意味します。
-
OrientDBdatabase内にクラスターを作成することもできます。これは、同様のタイプまたは値のレコードのグループです。 このようなクラスターは、複数のサーバーにまたがって存在することも、1つのサーバーに限定することもできます。
この記事の焦点は、最初の種類のクラスター、つまり ノードのクラスター。 クラスターモードでは、OrientDBはマルチマスターまたはマスターレスの分散アーキテクチャで実行されます。つまり、クラスター内のすべてのノードは同等の基盤で動作し、互いのレコードを読み書きできます。 ただし、ノードはreplicaとしてクラスターに参加することもでき、読み取り専用モードで動作します。
このチュートリアルでは、OrientDBのコミュニティエディションを使用して、2つのマスターノードと1つのレプリカノードで3ノードのクラスターをセットアップします。
前提条件
このチュートリアルを実行するには、次のものが必要です。
-
クラスタをサポートするのに十分なRAMを備えた3つのUbuntu 16.04サーバー。 これは、ニーズとOrientDBのカスタマイズ方法によって異なりますが、それぞれ4 GBが適切なデフォルトです。
-
sudoの非rootユーザーアカウントとファイアウォールは、this Initial Server Setup with Ubuntu 16.04 tutorialを使用してon each serverを設定します。
-
Javaはすべてのサーバーにインストールする必要があります。これは、the JDK 8 step of this Java installation guideに従うことで実行できます。 OpenJDK JREも機能するため、Oracleライセンスに同意したくない場合は、同じチュートリアルを使用してデフォルトのJREをインストールできます。
-
OrientDBは、Step 1 of the single server OrientDB installation guideを記述どおりに実行することにより、on each serverをインストールしました。 オプションでステップ2に従って、必要なRAMの量を制限することもできます。 OrientDB分散起動スクリプトは、少なくとも4 GBのRAMが使用可能であることを想定しており、これを変更しない限り、少ない場合は起動に失敗します。
-
OrientDBは、Steps 5 and 6 of the single server OrientDB installation guideに従って、Systemdサービスon each serverとしてセットアップされ、ユニットをリロードした後に停止します(つまり、 サービスを開始せずに)。 行う必要がある唯一の変更は、ユニットファイルの
ExecStart
に指定するファイルです。 元のチュートリアルではserver.sh
を使用していますが、ここでは分散モードにdserver.sh
を使用しています。
[[step-1 -—- generate-the-root-password-and-orientdb-instance-name]] ==ステップ1—ルートパスワードとOrientDBインスタンス名の生成
まず、分散サーバースクリプトdserver.sh
を実行して、OrientDBのインスタンスがクラスター内で機能するために必要な資格情報を生成します。 具体的には、これにより、OrientDBのインスタンスのルートパスワードと名前を設定できます。 all three serversでこの手順を実行する必要があります。
開始するには、インストールディレクトリに移動します。
cd /opt/orientdb
次に、分散サーバーを起動します。
sudo bin/dserver.sh
分散サーバーを初めて起動するときに、rootユーザーアカウントのパスワードを指定するように求められます。 これは、OrientDB Studio、OrientDBを管理するためのWebベースのインターフェイス、コンソールからOrientDBへの接続などのためにサーバーにアクセスするために使用される内部OrientDBアカウントです。 ここでパスワードを指定しない場合、パスワードは自動的に生成されます。 ただし、自分で指定することをお勧めします。次のプロンプトが表示されたら、指定してください。
Output+---------------------------------------------------------------+
| WARNING: FIRST RUN CONFIGURATION |
+---------------------------------------------------------------+
| This is the first time the server is running. Please type a |
| password of your choice for the 'root' user or leave it blank |
| to auto-generate it. |
| |
| To avoid this message set the environment variable or JVM |
| setting ORIENTDB_ROOT_PASSWORD to the root password to use. |
+---------------------------------------------------------------+
Root password [BLANK=auto generate it]: *****
Please confirm the root password: *****
次に、OrientDBのインスタンスの名前を設定するように求められます。これは、実行中のクラウドサーバーの名前と同じにすることができます。
Output+---------------------------------------------------------------+
| WARNING: FIRST DISTRIBUTED RUN CONFIGURATION |
+---------------------------------------------------------------+
| This is the first time that the server is running as |
| distributed. Please type the name you want to assign to the |
| current server node. |
| |
| To avoid this message set the environment variable or JVM |
| setting ORIENTDB_NODE_NAME to the server node name to use. |
+---------------------------------------------------------------+
Node name [BLANK=auto generate it]: node-name
スクリプトの実行が完了すると、次のような行が表示されます。
Output2017-06-01 02:24:00:717 INFO OrientDB Server is active v2.2.20 (build 76ab59e72943d0ba196188ed100c882be4315139). [OServer]
この時点で、CTRL+C
を使用してプロセスを終了できます。 OrientDBがインストールされたので、いくつかの構成ファイルを変更して、クラスターとして実行できるようにする必要があります。
[[step-2 -—- configuring-orientdb-to-function-in-distributed-mode]] ==ステップ2—分散モードで機能するようにOrientDBを構成する
OrientDBのインストールをクラスター内のノードとして機能させるには、そのconfig
ディレクトリー内の3つのファイルを変更する必要があります。 彼らです:
-
hazelcast.xml
:このファイルで定義されたパラメータにより、ノードの自動検出が可能になります。 -
default-distributed-db-config.json
:このファイルは分散環境でのみ使用するためのものであり、各データベースのノードの動作を定義するために使用されます。 -
orientdb-server-config.xml
:これは、分散モードかスタンドアロンモードかに関係なく変更する必要があるメインのOrientDB構成ファイルです。
このステップでは、hazelcast.xml
から始めて各ファイルを変更します。
hazelcast.xml
ファイルの変更
hazelcast.xml
で構成する必要がある最も重要な設定は、各ノードがクラスターに参加するために使用するメカニズムです。 このセクションで検討する2つのメカニズムは、IP MulticastとTCP/IP-clusterです。 前者では、各ノードが属するネットワークを自動検出するために使用するマルチキャストアドレスとポートを指定します。 後者では、各クラスターメンバーのIPアドレスを指定する必要があります。 IPマルチキャストはDigitalOceanではサポートされていないため、ここで使用する方法はTCP / IPクラスターです。
開始するには、ファイルを編集用に開きます。
sudo nano /opt/orientdb/config/hazelcast.xml
ファイルはそれほど長くありません。 これは、変更するファイルのセクションのみを示す切り捨てバージョンです。
/opt/orientdb/config/hazelcast.xml
. . .
orientdb
orientdb
. . .
2434
235.1.1.1
2434
このファイルに対して行うことは、IPマルチキャストを無効にし、TCP / IPクラスターを有効にするエントリを追加し、クラスターメンバーを指定することです。 各タグを見ていきましょう。
-
group > name:この要素は、クラスターの名前を定義します。 好きなものを選択できます。
-
group > password:クラスターに参加するために各メンバーによって送信されるブロードキャストメッセージを暗号化するために使用されるパスワードを定義します。 ここで強力なパスワードを選択してください。
-
network > port:ノードの自動検出に使用されるポートを識別します。
auto-increment
属性は、定義されたポートから開始し、そのポートが使用されている場合は他のポートを試行し続けるようにメカニズムに指示します。 falseに設定すると、定義されたポートが通信に使用され、ポートが既に使用されている場合、ノード検出は失敗します。 この記事では、属性は無効になります。 -
join > multicast要素は、IPマルチキャストパラメータを定義するために使用されます。 IPマルチキャストは使用しないため、無視します。 つまり、
enabled
属性をfalseに設定します。 -
join > tcp-ip:これはTCP / IPクラスター関連のパラメーターを定義するために使用されます。
enabled
属性はそれを有効にするために使用されます。 -
join > tcp-ip > member:クラスターの各メンバーを定義します。 各メンバーを指定する方法は他にもありますが、各メンバーのIPアドレスが指定されている(1行に1つずつ)この方法に固執します。
ファイルの変更が完了すると、最終バージョンは次のようになります。
/opt/orientdb/config/hazelcast.xml
. . .
clusterName
clusterPassword
. . .
2434
235.1.1.1
2434
your_master_server_ip_1
your_master_server_ip_2
your_replica_server_ip
編集が完了したら、ファイルを保存して閉じます。 次は、リストの2番目のファイルです。
default-distributed-db-config.json
ファイルの変更
hazelcast.xml
と同様に、/opt/orientdb/config/default-distributed-db-config.json
にいくつかの変更を加えます。 このファイルでは、各サーバーがクラスターで果たす役割(マスターまたはレプリカ)を指定します。
編集用に開きます。
sudo nano /opt/orientdb/config/default-distributed-db-config.json
ファイルの関連部分は、以下のコードブロックに示されています。
/opt/orientdb/config/default-distributed-db-config.json
{
"autoDeploy": true,
"readQuorum": 1,
"writeQuorum": "majority",
"executionMode": "undefined",
"readYourWrites": true,
"newNodeStrategy": "static",
"servers": {
"*": "master"
},
. . .
}
各行の意味は次のとおりです。
-
autoDeploy:データベースをまだ持っていないクラスター内の新しいノードにデータベースをデプロイするかどうかを指定します。
-
readQuorum:読み取り操作でクライアントに応答する前にコヒーレントである必要があるクラスターノードからの応答の数。 「1」に設定すると、読み取り一貫性が無効になります。
-
writeQuorum:書き込み操作で、クライアントに応答を送信する前に応答する必要があるノードの数。 デフォルトはmajorityで、これは(N/2) + 1を使用して計算されます。ここで、Nはクラスター内で使用可能なマスターノードの数です。 多数決を計算するとき、レプリカノードは考慮されません。 マスターノードが2つしかないクラスターでデフォルトのままにしておくと、ノードの1つがダウンしても定足数は形成されません。
-
executionMode:クライアントの実行モード(同期または非同期)を定義します。 デフォルトでは、クライアントが決定できます。
-
readYourWrites:ノードの応答が書き込みクォーラムに到達するためにカウントするかどうかを指定します。
-
newNodeStrategy:新しいノードがクラスターに参加するとどうなりますか。 デフォルト値では、ノードはサーバーのリストの下に自動的に登録されます。
以下のパラメーターを追加します。
-
hotAlignment:ノードがダウンしてからオンラインに戻った場合に何が起こるかを指定します。 有効にすると、ノードがオフラインのときに同期メッセージが分散キューに保持されます。 オンラインに戻ると、キュー内のすべての同期メッセージをポーリングして同期フェーズを開始します。
-
servers:クラスター内のノードの役割(マスターまたはレプリカ)を指定するために使用されます。 デフォルトでは、アスタリスク
*
は、サーバー内のすべてのノードがマスターになることを示すために使用されます。 2つのマスターと1つのレプリカを含むクラスターを構築するため、各ノードの名前とクラスター内での役割を指定して、このパラメーターを変更して一致させます。 名前は、ステップ1で構成したものです。
ファイルの変更が完了すると、次のようになります。
/opt/orientdb/config/default-distributed-db-config.json
{
"replication": true,
"hotAlignment" : true,
"autoDeploy": true,
"readQuorum": 1,
"writeQuorum": "majority",
"executionMode": "undefined",
"readYourWrites": true,
"newNodeStrategy": "static",
"servers": {
"orientdb_server_name_1": "master",
"orientdb_server_name_2": "master",
"orientdb_server_name_3": "replica"
},
...
}
完了したら、ファイルを保存して閉じます。 リストの最後のファイルを構成します。
orientdb-server-config.xml
ファイルの変更
/opt/orientdb/config/orientdb-server-config.xml
内には、OrientDBのHazelcastインメモリデータグリッドを使用してクラスタリングを有効または無効にするために使用されるパラメータがあります。 手順1でOrientDBインスタンスに付けた(またはスクリプトの自動生成を行った)名前は、このファイルで変更できます。
編集用に開きます。
sudo nano /opt/orientdb/config/orientdb-server-config.xml
ファイルの関連するセクションを以下に示します。これはファイルの上部にあります。 NodeNameパラメータの値がステップ1で指定したものであることに注意してください。
/opt/orientdb/config/orientdb-server-config.xml
. . .
. . .
クラスタリングを有効にするには、enabledパラメータをtrueに変更します。 編集後、最終バージョンは次のようになります。
/opt/orientdb/config/orientdb-server-config.xml
. . .
. . .
ファイルの編集が終了したら、保存して閉じます。
クラスターを開始してテストする前に残っているのは、OrientDBのトラフィックがファイアウォールを通過できるようにすることだけです。
[[step-3 -—- allowing-orientdb-traffic-through-the-firewall]] ==ステップ3—ファイアウォールを通過するOrientDBトラフィックを許可する
ここでクラスターを起動しようとすると、OrientDBのトラフィックはファイアウォールによってブロックされます。 次のポートを通過するトラフィックを許可するルールを追加しましょう。
-
2424
、バイナリ通信に使用 -
2434
、クラスター通信の交換に使用
ポート2424
および2480
を開きます。
sudo ufw allow 2424
sudo ufw allow 2434
[。注意]##
Note:ポート2480
は、アプリケーションのWebインターフェイスであるOrientDBStudioにアクセスするために使用されます。 これはHTTPを使用するため、安全ではなく、パブリックインターネットに公開されるべきではありません。 ただし、テストセットアップでこのポートのトラフィックを許可する場合は、次の方法で許可できます。
sudo ufw allow 2480
次に、UFWを再起動します。
sudo systemctl restart ufw
OrientDBは前提条件からSystemdサービスとしてすでに設定されているため、残りの構成が完了したので、クラスターを開始できます。
[[step-4 -—- starting-and-testing-the-orientdb-cluster]] ==ステップ4—OrientDBクラスターの開始とテスト
各サーバーで、起動時にサービスが開始されるように、サービスが有効になっていることを確認します。
sudo systemctl enable orientdb
これで、3つのサーバーすべてを起動できます。 最初のサーバーが起動しました(つまり、 最初にクラスターに参加する)はcoordinator serverになり、ここで分散操作が開始されます。 特定のサーバーにその役割を持たせたい場合は、まずその役割を開始します。
sudo systemctl start orientdb
プロセスのステータスをチェックして、それらが正しく開始されたことを確認します。
sudo systemctl status orientdb
次のような出力が表示されます。
Output● orientdb.service - OrientDB Server
Loaded: loaded (/etc/systemd/system/orientdb.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2017-06-01 02:45:53 UTC; 7s ago
サーバーが起動しない場合は、出力で手がかりを探してください。 エラーの潜在的な原因には、RAMの不足、Java JREがインストールされていない、または検証に失敗した変更されたJSONファイルが含まれます。 手順2のファイルに変更を加えた場合は、OrientDBを再起動することを忘れないでください。
プロセスが正しく実行されたら、クラスターが正常に動作していることをテストしましょう。 3つのノードのいずれかで、クラスターに関連するsyslogエントリーをフィルターします。
sudo tail -f /var/log/syslog | grep -i dserver
このコマンドを使用すると、クラスターのすべてのメンバーがオンラインであることを示す以下のような出力が表示されます。 アスタリスクは、どのマスターがコーディネーターサーバーであるかを示します。
Output-------------------+------+------------------------------------+-----+---------+-------------------+
|Name |Status|Databases |Conns|StartedOn|Binary |
-------------------+------+------------------------------------+-----+---------+-------------------+
|orientdb-replica-1|ONLINE|GratefulDeadConcerts=ONLINE (MASTER)|4 |01:26:00 |111.111.111.111
|orientdb-master-2 |ONLINE|GratefulDeadConcerts=ONLINE (MASTER)|4 |01:25:13 |222.222.222.222
|orientdb-master-1*|ONLINE|GratefulDeadConcerts=ONLINE (MASTER)|6 |01:24:46 |333.333.333.333
サーバーとそのデータベースがオンラインである場合、クラスターが適切に機能している可能性が高いため、これは良い兆候です。 同様の出力も表示されますが、以下のコンソールからデータベースの1つに接続すると、詳細が表示されます。 CTRL+C
を押すと、今のところこの出力を停止できます。
クラスター全体の新しいデータのデータ複製を検証するには、1つのサーバーでデータを生成し、それが他のサーバーに複製されるかどうかを確認する必要があります。 On one of the master servers、次のコマンドのペアを使用してコンソールを起動します。
cd /opt/orientdb/bin
sudo ./console.sh
最後のコマンドは、コンソールの起動中に次の出力を表示し、プロンプトをorientdb>
に変更する必要があります。
OutputOrientDB console v.2.2.17 (build UNKNOWN@r98dbf8a2b8d43e4af09f1b12fa7ae9dfdbd23f26; 2017-02-02 07:01:26+0000) www.orientdb.com
Type 'help' to display all the supported commands.
Installing extensions for GREMLIN language v.2.6.0
orientdb>
次に、OrientDBサーバーインスタンスに接続します。 このコマンドは、データベースではなく、rootユーザーアカウントを使用してサーバー上で実行されているOrientDBのインスタンスに接続するだけです。 パスワードは、ステップ3で作成したものです。
connect remote:localhost root root-password
次に、CallMeMaybe
という名前のデータベースを作成しましょう。
create database remote:localhost/CallMeMaybe root root-password plocal
データベースが正常に作成された場合は、データベースに接続し、プロンプトが一致するように変更する必要があります。
[.note]#Note:「アクセスが拒否されました」などのエラーが発生した場合は、/opt/orientdb/databases
ディレクトリのアクセス許可を確認してください。 コンソールからデータベースを作成するアカウントには、そのフォルダーに対する読み取りおよび書き込み権限が必要です。 詳細については、this Linux permissions tutorial。
#をご覧ください。
現在、CallMeMaybe
はまだ空のデータベースです。 テストデータを取得するために、クラスを追加してみましょう。
create class Artist
次に、レコードを挿入します。
insert into Artist (id, name, age) values (01,'sammy', 35)
挿入したばかりのレコードが新しいデータベースに保持されていることを確認します。
select id, age, name from Artist
すべてうまくいった場合、出力は次のようになります。
Output+----+----+----+------+
|# |id |age |name |
+----+----+----+------+
|0 |1 |35 |sammy |
+----+----+----+------+
1 item(s) found. Query executed in 0.216 sec(s).
これでコンソールを終了できます。
exit
この検証プロセスの最後の手順は、クラスター内の別のノードにログインし、新しいデータベースにクエリを実行して、データが正常に伝達されたかどうかを確認することです。
ssh sammy@another_orientdb_server_ip
前と同じようにコンソールを起動します。
cd /opt/orientdb/bin
sudo ./console.sh
新しいOrientDBデータベースのデフォルトのユーザーとパスワードであるadminとしてデータベースに接続します。
connect remote:localhost/CallMeMaybe admin admin
前と同じクエリを実行します。
select id, age, name from Artist
出力は以前のサーバーの出力と同じである必要があります。サーバーのクラスター全体でクエリを実行しているためです。 これでコンソールを終了できます。
exit
これにより、3ノードクラスターが正しく機能していることが確認されます。
結論
異なる役割(マスターまたはレプリカ)を提供する3つのノードで構成されるOrientDBクラスターをセットアップしました。 このようなセットアップでは、ノードの数を簡単に変更できます。 さらに簡単で、楽しく、タスクが少なくなるのは、a configuration management tool like Ansibleを使用して、このようなクラスターのデプロイメントを自動化することです。
今のところ、クラスター内の各ノードを保護する方法を学ぶためにconsult this OrientDB security guideを実行することをお勧めします。 OrientDB管理に関する公式ドキュメントはproject’s documentation siteで入手できます。また、Hazelcastの詳細については、the Hazelcast documentationにアクセスしてください。