OCI Big Data Service のインスタンスを立ててみた

はじめに : Oracle Big Data Service

Oracle Cloud Infrastructure (OCI) におけるビッグデータ活用向けのサービスとして、 Oracle Big Data Service がリリースされています。こちら、 Cloudera 社の CDH をベースとしたサービスで Hadoop / Spark 等を利用可能なプラットフォームを提供します。

今回は、 Big Data Service のインスタンスを作成し、様子を確認してみます。

ドキュメントは以下です。

Oracle Big Data Service

事前準備

VCN 作成

Big Data Service は特定の VCN 内に配置されるので、事前に VCN を作っておく必要があります。 Public / Private いずれでもいけますが、 Regional Subnet である必要があります。

ポリシーの追加

Big Data Service が VCN とうにアクセスできるよう、ルートコンパートメントに以下のポリシーを追加しておきます。

allow service bdsprod to {VNIC_READ, VNIC_ATTACH, VNIC_DETACH, VNIC_CREATE, VNIC_DELETE, VNIC_ATTACHMENT_READ, SUBNET_READ, VCN_READ, SUBNET_ATTACH, SUBNET_DETACH, INSTANCE_ATTACH_SECONDARY_VNIC, INSTANCE_DETACH_SECONDARY_VNIC} in tenancy

ユーザ

OCI Administrator グループに入っているユーザで進めます。

Big Data Service インスタンスの作成

Big Data Service のインスタンスは「データおよびAI」の下の「ビッグ・データ」から作ります。

Big Data Service のページに行くと、「クラスタの作成」を行うことができます。

クラスタの作成画面は横からひゅーっと出てくるタイプです。クラスタ名とクラスタの管理パスワードを設定します。また、その下に「セキュアで高い可用性(HA)」というメニューがあるのですが、このチェックをつけると Master Node / Utility Node が冗長構成になります。試しに作ってみるレベルなのでチェックを外しておきます。

クラスタ・バージョンについては現時点では CDH 6.3 のみとなっており CDH 7 系の提供はありません。ドロップダウンリストになっているので、そのうち追加されるものと思います。

ちなみに、トライアルアカウントでは、非 HA 構成のインスタンスは作成できるようです。(それなりにノード数、リソースが必要なので、なかなか速くクレジットが消費されてしまうかもしれませんが。。)

Big Data Service Regions, Limits, Quotas, Events, and Work Requests

このあと、 Master / Utility ノードの構成選択に移ります。Master / Utility ノードは VM.Standard2.4 が最小です。 先ほどの HA を有効化すると Mater x2 / Utility x2 の構成になります。なお、E2 / E3 シェイプには対応していません。ブロックストレージのサイズもここで選択します。試しに作ってみるだけなので最低の 150 GB にしておきます。

その後 Worker ノードの構成も同じように選択します。VM.Standard2.1 x3ノードが最小構成です。

この後はネットワークの設定です。ネットワーク設定は若干固有のものがあり、「クラスタ・プライベート・ネットワーク」が構成されます。こちら VCN とは別に構成されるノード間のネットワークとなり、 CIDR ブロックのみ指定します。デフォルトですと 10.0.0.0/16 と記載がありますが、今回は VCN とかぶるので 10.1.0.0/16 としました。

顧客ネットワークが VCN 側の設定です。

その後の「ネットワーキング・オプション」ですが、取り急ぎ作ってみるだけなので、「オラクル社が～」を設定します。後述しますが、これを選ぶと、NAT ゲートウェイ等の設定がうまくいってなくてもインスタンスからの Outbound の通信ができるように取り計らってくれるオプションのようです。

SSH 公開キーについては、各ノードへのアクセスに使うキーになりますので、公開鍵を追加しておきます。

これでクラスタの作成をクリックすると、クラスタの作成が始まります。

構成の確認

体感的には 20 - 30分ぐらい待つとインスタンスがアクティブになります。5ノードプロビジョニングされてます。クラスタの名前をクリックして詳細を確認します。

「ネットワーキング・オプション」で「オラクル社が～」を選んだのでプライベート・ネットワーク側に NAT ゲートウェイがプロビジョニングされています。上のメニューからもわかるように、ブロック・ストレージの追加やシェイプ変更等はこの画面からできるようです。

なお、 2020/11 時点では停止のメニューはないようです。

Big Data Service のクラスタ自体は CDH をベースにしているのですが、 OCI 特有のサービスとして Cloud SQL があります。画面上も説明されていますが、 HDFS や オブジェクト・ストア (OCi Object Storage や AWS S3 等)に対して、 RDBMS (Oracle Database) のインターフェースを介してアクセスできるようにするものです。 Cloud SQL のノードは、 Big Data Service クラスタの構築後に追加します。

Cloud SQL については興味深いのでまた別の機会に試してみます。

ノードの一覧、詳細も確認できます。

Public IP アドレスの構成

Big Data Service のノードは、 Public Subnet にたてた場合でもデフォルトでは Private IP アドレスのみ構成されるため、各ノードや管理画面にアクセスするためには踏み台経由もしくは Public IP アドレスを割り当ててやる必要があります。

今回は以下のドキュメントに沿って、 Public IP アドレスを割り当てます。

Map a Private IP Address to a Public IP Address

Public IP アドレスは Cloud Shell から OCI CLI を利用する方法で割り当てるやり方がガイドされています。

上記ドキュメントの通り、以下を Cloud Shell で実行します。事前に確認しておくべきこととしては、「Subnet の OCID」、 Public IP アドレスを割り当てるノードの Private IP アドレスです。ここでは Utility Node に Public IP アドレスを振ります。なお、DISPLAY_NAME はオプションで、 Public IP 予約につける名称です。

export DISPLAY_NAME=testbdsun0
export SUBNET_OCID=ocid1.subnet.oc1.ap-tokyo-1.aaaaaaaahit2cop62r6gyxijyh4cbutva4nsua5axwctwc3eidubc2yazlmq
export PRIVATE_IP=10.0.0.10
oci network public-ip create --display-name $DISPLAY_NAME --compartment-id `oci network private-ip list --subnet-id $SUBNET_OCID --ip-address $PRIVATE_IP | jq -r '.data[] | ."compartment-id"'` --lifetime "RESERVED" --private-ip-id `oci network private-ip list --subnet-id $SUBNET_OCID --ip-address $PRIVATE_IP | jq -r '.data[] | ."id"'`

上記実行すると、以下のような結果が返ってきて、 Public IP アドレスが紐付けられます。

これでインスタンスに SSH 接続できるようになりました。(22 ポートはあらかじめ開けています)

[opc@testbdsun0 ~]$ hostname -a
testbdsun0.sub11260434160.bdsvcn.oraclevcn.com. testbdsun0

ちなみにノードのインターフェースを確認してみると ens3 としてクラスタ・プライベート・ネットワークが構成されており、VCN 側のネットワークは ens5 として構成されています。

[opc@testbdsun0 ~]$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether 02:00:17:01:74:eb brd ff:ff:ff:ff:ff:ff
    inet 10.1.0.5/16 brd 10.1.255.255 scope global dynamic ens3
       valid_lft 68500sec preferred_lft 68500sec
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether 02:00:17:00:39:38 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.10/24 scope global ens5
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:26:c0:3a:d2 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
8: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default 
    link/ether de:43:67:5c:a5:ce brd ff:ff:ff:ff:ff:ff
    inet 10.244.0.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever
9: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
    link/ether da:2e:ba:ac:c6:07 brd ff:ff:ff:ff:ff:ff
    inet 10.244.0.1/24 brd 10.244.0.255 scope global cni0
       valid_lft forever preferred_lft forever
10: veth08322d14@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default 
    link/ether 1e:16:ad:d2:c9:40 brd ff:ff:ff:ff:ff:ff link-netnsid 1
11: vetha9d6e5ab@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default 
    link/ether 32:c5:dd:54:3d:bd brd ff:ff:ff:ff:ff:ff link-netnsid 2
12: vethfa5146a1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default 
    link/ether 4a:3d:05:cf:0d:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 3
14: vethb0572403@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default 
    link/ether 5e:a5:10:fe:83:cf brd ff:ff:ff:ff:ff:ff link-netnsid 4

route -n してみると、デフォルトゲートウェイはクラスタ・プライベート・ネットワーク側(10.1.0.1)に向いていました。「ネットワーキング・オプション」のところで、 NAT ゲートウェイがクラスタ・プライベート・ネットワークに構成される、というのは個々に聞いてくるようです(「オラクル社が～」じゃなかったときにルーティングテーブルがどうなるのかは、すみません、確認できてません)

[opc@testbdsun0 ~]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.0.1        0.0.0.0         UG    0      0        0 ens3
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 ens5
10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        0 ens3
10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 ens3
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 ens3
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

Cloudera Manager 等へのアクセス

この後追加で Security List に必要なルールを追加して Cloudera Manager 等へアクセスしてみます。

ドキュメントによれば、以下のポートで構成されているとのことです(Cloud SQL のポートが 1521 っていうのがオラクルっぽい)。

• Cloudera Manager - port 7183

• Hue - port 8888

• Web Resource Manager - port 8090

• Spark History Server - port 18088

• Cloud SQL (if Cloud SQL is installed) - port 1521

  あんまり良くないかとも思ったのですが、テスト用なので、とりあえずアクセス元の IP アドレスだけ制御して上記ポートをあけます。

上記追加したら、 Cloudera Manager にアクセスします。以下のアドレスでアクセス可能です。

https://<ユーティリティノードのip_address>:7183

セキュリティの警告等が出るかと思いますが進めます。画面が表示されましたら、ユーザ名は admin / パスワードはインスタンス構築時に指定したクラスタ管理パスワードでログインします。

Cloudera Manager の画面が確認できました。 HDFS / Hive / Hue / Oozie / Spark 等が構成されていることが確認できます。

まとめ

今回は Big Data Service のインスタンスをとりあえず作ってみました。ネットワークの設定等、ちょっとあらけずり感のあるところもありますが、 Cloudera 環境を OCI 上でかんたんに構成することができました。

今後 Cloud SQL や他のサービスとの連携についても考えてみたいと思います。