NAKAMURA Minoru の日記 (2020年11月)

ブレーカーが落ちた

朝方、エアコンの暖房を入れた後にオーブントースターでトーストを焼いているとブレーカーが落ちてしまった。 このアパートは契約電力が20A。 オーブントースターが1200Wでエアコンの暖房が860W。 その他、常時ついているパソコンの電力消費によって定格を越えたようだ。

さすがにオーブントースターや炊飯器とエアコンが同時に使えないのでは困るので、電力会社に電話して20A→30Aに変更してもらうが工事は月曜になるとのこと。

追記: 11/30

工事の人が来て30Aに変更してもらえた。

[Java] Kerberos ドメイン外から HDFS に接続する

Hadoop のセキュアモードは、Hadoop を構成する各ノードのローカル OS が Kerberos 傘下に入ることを必要としている。 Kerberos 傘下に入るには、Kerberos サーバー(以下、KDC)への登録と Kerberos 管理者から keytab ファイルの提供を受ける必要がある。 そのため Kerberos 傘下に入らずに Hadoop のサービスへアクセスするには、Apache Knox Gateway などを使わない場合以外は不可能だった。

しかし HDFS クラスタ―とのデータをやり取りするファイルビュー的なものを作りたい場合、ファイルビューを動かすノードまで Kerberos 傘下にするのは現実的ではない。 なんとか Kerberos ドメインの外側から HDFS にアクセスしたと思って試行錯誤していた。

Hadoop RPC は難しそう

クライアントが HDFS にアクセスする場合、通常は独自の RPC 通信を行う。 この RPC 通信は非セキュアモード構成では認証なし、セキュアモード構成では SPNEGO 認証(Kerberos)が行われる。

最初に考えたのは HDFS へのアクセスを担当している org.apache.hadoop.hdfs.DistributedFileSystem を継承して、SPNEGO 認証を行っている箇所を修正するという方法。 このクラスは fs.hdfs.impl というプロパティで変更することができる(ようだ)。 ただし DistributedFileSystem クラスは重要なフィールドが package protected 修飾されているので、継承してもアクセスができない。 大規模に書き換える必要があるようだ。

また DistributedFileSystem クラスの中で実際に通信を担当すると思われる org.apache.hadoop.hdfs.DFSClient をかなり複雑な経路を辿って Java SASL API を呼び出しその中で SPNEGO 認証を行っているようで、どこを変更すればよいのかよくわからない。

2020-11-1610:16:07,816DEBUGsecurity.SaslRpcClient: client isn't using kerberos
2020-11-1610:16:07,816DEBUGsecurity.UserGroupInformation: PrivilegedActionException as: hdfs (auth:SIMPLE)
org.apache.hadoop.security.AccessControlException: Client cannot authenticate via:[TOKEN,KERBEROS]
    at org.apache.hadoop.security.SaslRpcClient.selectSaslClient(SaslRpcClient.java:179)
    at org.apache.hadoop.security.SaslRpcClient.saslConnect(SaslRpcClient.java:392)
    at org.apache.hadoop.ipc.Client$Connection.setupSaslConnection(Client.java:622)
    at org.apache.hadoop.ipc.Client$Connection.access$2300(Client.java:413)
    at org.apache.hadoop.ipc.Client$Connection$2.run(Client.java:822)
    at org.apache.hadoop.ipc.Client$Connection$2.run(Client.java:818)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:422)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1845)
    at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:818)
    at org.apache.hadoop.ipc.Client$Connection.access$3800(Client.java:413)
    at org.apache.hadoop.ipc.Client.getConnection(Client.java:1636)
    at org.apache.hadoop.ipc.Client.call(Client.java:1452)
    at org.apache.hadoop.ipc.Client.call(Client.java:1405)
    at org.apache.hadoop.ipc.ProtobufRpcEngine2$Invoker.invoke(ProtobufRpcEngine2.java:234)
    at org.apache.hadoop.ipc.ProtobufRpcEngine2$Invoker.invoke(ProtobufRpcEngine2.java:119)
    at com.sun.proxy.$Proxy9.getFileInfo(Unknown Source)
    at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:964)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:422)
    at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:165)
    at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:157)
    at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95)
    at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:359)
    at com.sun.proxy.$Proxy10.getFileInfo(Unknown Source)
    at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1731) ← ここでアクセス

REST API なら出来そう

これ以外の方法として、HDFS に REST API で通信する方法がある。 これが HttpFS と WebHDFS がある。 両者の違いは HttpFS はクライアントはゲートウェイサーバーを介してアクセスを行い直接データノードにアクセスする必要がないが、WebHDFS は HDFS に関係する全ノードにアクセスする必要がある。 そのため WebHDFS でファイルの内容を読むといった操作を行うと、データノードにリダイレクトが行われるようだ。 セキュアモードでは WebHDFS も HttpFS も REST API として SPENGO 認証(Kerberos)が行われる。

Kerberos ドメイン外から HDFS にアクセスするのに WebHDFS を使うことを考えたい。 検証用にまず Kerberos 認証の擬似クラスター Docker-Compose に対して SPNEGO 認証を行うテストコードを作成した。 これはデータノードへのリダイレクトには対応していないが、とりあえず SPNEGO 認証はパスしている。

その他の覚書

• MIT Kerberos を使う場合、/etc/krb5.conf の [libdefaults] の renew_lifetime はコメントアウトしておく必要がある。 指定するとエラーが発生する(Kerberized Hadoop Login failure for user … LoginException: Checksum failed、How to solve the `Message stream modified (41)` error on starting Kerberized components.)。
• WebHDFS を使うためには Web-console の設定も必要がある。 core-site.xml に以下を記述する。

  <property>
    <name>hadoop.http.authentication.type>/name>
    <value>>kerberos</value>
  </property>
  
  <property>
    <name>hadoop.http.authentication.kerberos.principal</name>
    <value>HTTP/_HOST@EXAMPLE.COM>/value<
  </property>
  
  <property>
    <name>hadoop.http.authentication.kerberos.keytab</name>
    <value>(keytab ファイルのパス)</value>
  </property>
  

• WebHDFS は Hadoop 3 系ではデフォルト有効で、ネームノード上で動作するが、dfs.namenode.http-address で指定したポート(デフォルトは 0.0.0.0:9870)
• HttpFS はセットアップが必要。

HDFS 実験用の Docker イメージ & Docker Compose

HDFS を簡単に構築する Docker コンテナが欲しいといつも思っているのだが、世の中にある Hadopp コンテナはどれもバージョンが古い。 自前で Apache Hadoop 3.3 の Docker コンテナイメージを作成している(1.)。

実際に使う場合は Docker Compose でクラスタ―を構成する。 HDFS の場合、ネームノードとデータノードは別にする。 実験用なのでレプリケーションセットは 1 とし、データノードは1台だけ。 セカンダリーネームノードはなしである。

2. は Kerberos を導入しない非 secure mode のクラスタ―。

3. は MIT Kerberos を使った secure mode のクラスタ―。

1. ベースとなる Hadoop コンテナイメージ
2. 非 Kerberos 認証の擬似クラスターの Docker-Compose
3. Kerberos 認証の擬似クラスター Docker-Compose

[Movie] シラノ・ド・ベルジュラックに会いたい

109シネマズ港北で『シラノ・ド・ベルジュラックに会いたい！』(原題: Edmond)を観る。 109シネマズ港北はセンター北にあるモザイクモール港北内。 ここで観るのは初めて。 というのも『シラノ・ド・ベルジュラックに会いたい！』は川崎では上映しておらず、小劇場系の映画館のみになっている。

映画としては『ラヂオの時間』や『カメラを止めるな!』のような、いろんなトラブルにみまわれながらも劇中劇を完成させるコメディ。 ただこっちは実在の「シラノ・ド・ベルジュラック」はフランス演劇の傑作と名高い作品で、成功が約束されているので安心して見れる。 今年観た映画の中では一番面白かった。

[Food] バケット＠センター北

映画館の入っているモザイクモール港北で昼食をとる。 お店はバケット(公式、食べログ)。 ここはラゾーナ川崎のBISTRO 309のように小さなパンの食べ放題がついている。

ミックスグリルのアヒージョを食べる。 これに小さなパンを合わせて食べるのはなかなか美味い。

プラスチックダンボールを入手

センター北にはホームセンター コーナンがあった。 ここで 900mm×600mm のプラスチックダンボールを2枚購入。

[Movie] 羅小黒戦記 ロシャオヘイセンキ　ぼくが選ぶ未来

川崎チネチッタで『羅小黒戦記 ロシャオヘイセンキ ぼくが選ぶ未来』の吹替版を観る。

中国のアニメを劇場で観るのは初めてだが、吹き替え花澤香菜、宮野真守、櫻井孝宏なんでこう陳腐化している。 字幕版を観たかったが、周辺の劇場では既に上映終了しているようだ。

追記: 2021/1/1

川崎チネチッタで字幕版を見た。 「吹き替え花澤香菜、宮野真守、櫻井孝宏なんでこう陳腐化している」と書いたが、元の声優さんの声と非常に似ている。 本人が中国語で声をあてているんじゃないかと思うぐらいだ。

大江戸温泉物語

今日はお台場の大江戸温泉物語へ行ってみる。

ここは入り口で浴衣に着替えた後に、縁日風の商業エリアに入って、そこからお風呂に向かうというシステムだった。

ニトリで買ったパーソナルチェアが届く

IKEA で買った一人かけの STRANDMON(ストランドモン)ウィングチェア(2016年11月3日の日記)は、引っ越しの時に手放してしまった。 がっしりとした作りのパーソナルチェアだが、リクライニング付の椅子か、ごろっと横になれるソファーが欲しくなったからだ。

いろいろ調べてニトリの Nシールド ロード4 IVというのを購入した。 同じような形の奴で布や本革のものがあるが合成革の奴を選択。 オプションでサイドに配置可能なタブレット台も購入。

で今日、配送されてきた。 自分で組み立ててみる。 こう強度に不安を感じる構造だが、5年保証もあるし大丈夫だろう。

この椅子に寝そべりながらテレワークを行えるようになるのが目的。

Azure のストレージサービス

Azure の SaaS 的に使えるストレージサービスを調査中。 備忘録を書いておく。

Azure Blob Storage (通称 Blobs、アクセス時のスキーマは WASB)

Amazon S3 風のオブジェクトストレージ。
S3 との大きな違いは仮想フォルダーの実体を作れないこと。 S3 も Blob Storage は foo/bar/baz を作ると foo/ と foo/bar/ というプレフィックスが自動的に作成されるが、S3 の場合は空の仮想フォルダーを作成することができるが Blob Storage にはできない。

Azure Files (Azure File Shares と呼ばれることも)

SMB プロトコルでアクセスできるファイルストレージ。 REST API でのアクセス可能。
AWS でいうと Amazon FSx のような位置づけに見える。
他に NFS v4.1 でアクセスを可能とするオプションがあるが、機能制限があるようだ。

Azure Data Lake Storage Gen1 (アクセス時のスキーマは ADL)

よくわからない。 現在は Gen2 を使う方がよいようだ。

Azure Data Lake Storage Gen2 (通称 Data Lake、アクセス時のスキーマは ABFS)

Blob Storage をバッキングストアとして使い、その上で HDFS 互換の階層化されたファイルシステム層を見せたもの。 ディレクトリのリネームや別階層への移動や POSIX 風の ACL が使えるようになっている。
Data Lake Storage Gen2 は Blob Storage のインターフェイスからでもアクセスできるようだが、正常状態の Blob Storage のようには見えない。

上記のサービスはストレージアカウントを作成し、その下にストレージサービスを作ってゆく。 サービスへアクセスするための認証方法は、複数タイプがある。

Shared Key

ストレージアカウント毎にあるアクセスキーでアクセスする。 マスターキーに相当するストレージアカウントでアクセスしているのでセキュリティ的な懸念がある。

Shared Access Signature (SAS)

SAS はストレージアカウントのキーを使って署名し、派生したキーを作るもの。 アクセス可能なサービスや機能を制限できる。

Service SAS

サービス毎にキーを作る。

Account SAS

Service SAS と異なり一つのキーで複数のサービスにアクセスできる。 また制限が Service SAS よりも細かくできる。

User Delegation SAS

Azure AD のユーザーに紐づいた SAS キーを作れる。 ただし Blob Storage と Data Lake Storage Gen2 しかアクセスできない。 またユーザーに紐づいていてもそのアカウントでアクセスできる機能は preview のようだ。 有効期間は最長7日。

OAuth 2.0

Azure Managed Identity と Azure AD を連携し OAuth 2.0 を使った認可が可能。

Service Principal

User Principal

上記とは別に NetApp ベースの SMB サービス として Azure NetApp Files が提供されている。 Azure File Shares と被るが、SMB/NFS の両方でアクセスできる、差分が生じた時しか容量が増えないスナップショット等 NetApp ストレージと同様の機能が提供されているようだ。
ただ Microsoft のサービス体系とは統合されておらず、REST API からのアクセスはできない。 認証も別物。

[Java] Azure サービスを Java からアクセスする

Azure クラウドのサービスを Java からアクセスする方法を探しているが、いろいろ面倒くさいことになっている。

• AWS SDK はコンポーネントを横串で統一したバージョンが振られているが、Azure の場合は各コンポーネント毎にバージョンがバラバラに振られている。
• ストレージ系の SDK は V8 から V10 へ以降する際に、別物になった。 パッケージも com.microsoft.azure.storage から com.azure.storage に変更され API のコンセプトまで一新されている。 それが V12 でさらに機能追加されている。 (参考: 最近のAzure Client SDK事情 Java編)

• Microsoft | Java / Reference / Overview

V10 以降の Azure SDK for Java を使うとトラブルが多い。

• Azure SDK for Java は HTTP クライアントと REST API の呼び出しが分離しており、HTTP クライアントは Netty と OkHTTP を選択できるが、前者だとパスワード付きプロキシを使ったアクセスができない。
• Azure Blob Storage の listBlobs が無限に結果を返す([Bug] infinite iteration over blobList #9465)に遭遇。 ライブラリを大量導入していて、Jackson 系のライブラリが特定のバージョンになっていないと発生するようだ。 V8 では特に問題なく動作していたが…