Zoo Keeper権限制御
今は社内でZoo Keeperを使うところが増えています.自分でZKクラスタを作って使うのが好きです.ZKの高い利用可能性を考慮して、ZKクラスタが少なくとも3台のマシンをセットすると、各アプリケーション、特にいくつかの非コアアプリケーションが自分でセットを展開すると、リソースの利用率が低い.また、ZKフォースが提案されるにつれて、単セットのZKクラスタで使用されるマシンの量がより大きくなり、これに対してオペレータは懸念を持ち始め、ZKクラスタを統合したいと強く願っています.
ZKクラスタの合併使用自体はそれほど難しくないです.問題はアプリケーションがみんなでZKクラスタを共有することを望んでいるかどうかです.この中の一つが明らかな問題は権限です.もし私のデータが他の人に動かれたらどうすればいいですか?
会社の多くの牛人の助けのもとで、しばらく二つの権限案を得て、同時に自分の意見を提出して、一緒に進歩してほしいです.個人的にはzookeeperaclの権限制御方式を採用することを提案しています.
提案1:Zoo KeeperがサポートするACLdigest方式を採用し、ユーザー自身がノードの権限を定義する.
この方式はzookeeperのaclとdigest認証モードを結合する.
このアクセス許可プロセスをユーザー登録と見なしてもいいです.システムはあなたにパスワードを与えます.操作ごとにこのユーザ名とパスワードを使います.したがって、このような権限管理システムに対応して、ノードの作成申請を行うことができます.「申請プライベートノード」と「公開ノード」を含みます.このようにノードの作成はすべてこの権限管理システムが担当しています.申請が終わるたびに、システムはあなたのkeyに戻ります.フォーマットは通常「{appName}{password}」です.これからはあなたのどの操作もzksessionの中にこのkeyを携帯してください.これで権限制御ができます.もちろん、ユーザ自身がzkクライアントを介してpathを作成することも可能であり、彼らがライセンス方式を使用してzkノードの作成を行うことを要求するだけである.(注意、zkclientを使うなら、使ってください.https://github.com/nileader/zkclient)
権限制御フロー全体のコードテストは、下図のように大図をクリックしてください.(テストコードはここにあります.)
この案は大体このようです.1.AシステムにはIPとappNameのデータがあります.2.このデータをZKサーバで一部キャッシュし、タイミングでキャッシュ更新します.3.クライアントがサーバに対して要求を開始するたびに、クライアントipを取得して照会し、アプリNameに対応する権限があるかどうかを判断する.指定されたipは指定/appNameznodeのみ操作できます.4.その他の災害対策.
個人は2つの案を比較します.1.方案は方案の2より、ユーザーのコントロールが大きいので、オンラインでも日常でも、テストはアプリケーション開発者が自分で決定して権限を開くことができます.(案1の利点)2.案2は、使いやすさが強く、ユーザーの使用と権限がほぼ一致しています.(案二の優勢)3.案二より純潔である.zkはもともと1つの底の部品であるべきだと思っています.彼に他の上の階のもう一つのシステムに依存させます.権限の制御精度はシステムAにおける情報の正確さに依存する.(案一のメリット)
加えて、プログラムを添付します.3台のZKサーバ:8コアJDK 1.6.0-06 4台のzkクライアントマシン:5コアJDK 1.6.0-21テストシーン:800人の発表者、800個のパスに対応しています.各path 3人の予約者、合計2400人の予約者です.発表者はデータを発表して、購読者に通知します.結論:権限制御はzkのTPSに一定の影響を与えているが、まだ高い水準にある(1.3 w+)
ZKクラスタの合併使用自体はそれほど難しくないです.問題はアプリケーションがみんなでZKクラスタを共有することを望んでいるかどうかです.この中の一つが明らかな問題は権限です.もし私のデータが他の人に動かれたらどうすればいいですか?
会社の多くの牛人の助けのもとで、しばらく二つの権限案を得て、同時に自分の意見を提出して、一緒に進歩してほしいです.個人的にはzookeeperaclの権限制御方式を採用することを提案しています.
提案1:Zoo KeeperがサポートするACLdigest方式を採用し、ユーザー自身がノードの権限を定義する.
この方式はzookeeperのaclとdigest認証モードを結合する.
このアクセス許可プロセスをユーザー登録と見なしてもいいです.システムはあなたにパスワードを与えます.操作ごとにこのユーザ名とパスワードを使います.したがって、このような権限管理システムに対応して、ノードの作成申請を行うことができます.「申請プライベートノード」と「公開ノード」を含みます.このようにノードの作成はすべてこの権限管理システムが担当しています.申請が終わるたびに、システムはあなたのkeyに戻ります.フォーマットは通常「{appName}{password}」です.これからはあなたのどの操作もzksessionの中にこのkeyを携帯してください.これで権限制御ができます.もちろん、ユーザ自身がzkクライアントを介してpathを作成することも可能であり、彼らがライセンス方式を使用してzkノードの作成を行うことを要求するだけである.(注意、zkclientを使うなら、使ってください.https://github.com/nileader/zkclient)
権限制御フロー全体のコードテストは、下図のように大図をクリックしてください.(テストコードはここにあります.)
“
package org.I0Itec.zkclient;
import java.util.ArrayList;
import java.util.List;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.ZooDefs.Ids;
import org.apache.zookeeper.data.ACL;
/**
* Description: ZooKeepre ACL
* @author nileader / [email protected]
* @Date Feb 2, 2012
*/
public class DemoAuth implements Watcher {
final static String SERVER_LIST = “127.0.0.1:4711″;
final static String PATH = “/yinshi_auth_test”;
final static String PATH_DEL = “/yinshi_auth_test/will_be_del”;
final static String authentication_type = “digest”;
final static String correctAuthentication = “taokeeper:true”;
final static String badAuthentication = “taokeeper:errorCode”;
static ZkClient zkClient = null;
public static void main( String[] args ) throws Exception {
List< ACL > acls = new ArrayList< ACL >( 1 );
for ( ACL ids_acl : Ids.CREATOR_ALL_ACL ) {
acls.add( ids_acl );
}
try {
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, correctAuthentication.getBytes() );
} catch ( Exception e ) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
zkClient.createPersistent( PATH, acls, “init content” );
System.out.println( “ key:” + correctAuthentication + “ :” + PATH + “, : init content” );
} catch ( Exception e ) {
e.printStackTrace();
}
try {
zkClient.createPersistent( PATH_DEL, acls, “ ” );
System.out.println( “ key:” + correctAuthentication + “ :” + PATH_DEL + “, : init content” );
} catch ( Exception e ) {
// TODO Auto-generated catch block
e.printStackTrace();
}
//
getDataByNoAuthentication();
getDataByBadAuthentication();
getDataByCorrectAuthentication();
//
updateDataByNoAuthentication();
updateDataByBadAuthentication();
updateDataByCorrectAuthentication();
//
getDataByNoAuthentication();
getDataByBadAuthentication();
getDataByCorrectAuthentication();
//
deleteNodeByBadAuthentication();
deleteNodeByNoAuthentication();
deleteNodeByCorrectAuthentication();
deleteParent();
zkClient.close();
}
/** : */
static void getDataByBadAuthentication() {
String prefix = “[ ]“;
try {
System.out.println( prefix + “ :” + PATH );
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, badAuthentication.getBytes() );
System.out.println( prefix + “ :” + zkClient.readData( PATH ) );
} catch ( Exception e ) {
System.err.println( prefix + “ , :” + e.getMessage() );
}
}
/** : */
static void getDataByNoAuthentication() {
String prefix = “[ ]“;
try {
System.out.println( prefix + “ :” + PATH );
zkClient = new ZkClient( SERVER_LIST, 50000);
System.out.println( prefix + “ :” + zkClient.readData( PATH ) );
} catch ( Exception e ) {
System.err.println( prefix + “ , :” + e.getMessage() );
}
}
/** */
static void getDataByCorrectAuthentication() {
String prefix = “[ ]“;
try {
System.out.println( prefix + “ :” + PATH );
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, correctAuthentication.getBytes() );
System.out.println( prefix + “ :” + zkClient.readData( PATH ) );
} catch ( Exception e ) {
System.out.println( prefix + “ , :” + e.getMessage() );
}
}
/**
* :
*/
static void updateDataByNoAuthentication() {
String prefix = “[ ]“;
System.out.println( prefix + “ : ” + PATH );
try {
zkClient = new ZkClient( SERVER_LIST, 50000);
if( zkClient.exists( PATH ) ){
zkClient.writeData( PATH, prefix );
System.out.println( prefix + “ ” );
}
} catch ( Exception e ) {
System.err.println( prefix + “ , :” + e.getMessage() );
}
}
/**
* :
*/
static void updateDataByBadAuthentication() {
String prefix = “[ ]“;
System.out.println( prefix + “ :” + PATH );
try {
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, badAuthentication.getBytes() );
if( zkClient.exists( PATH ) ){
zkClient.writeData( PATH, prefix );
System.out.println( prefix + “ ” );
}
} catch ( Exception e ) {
System.err.println( prefix + “ , :” + e.getMessage() );
}
}
/**
* :
*/
static void updateDataByCorrectAuthentication() {
String prefix = “[ ]“;
System.out.println( prefix + “ :” + PATH );
try {
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, correctAuthentication.getBytes() );
if( zkClient.exists( PATH ) ){
zkClient.writeData( PATH, prefix );
System.out.println( prefix + “ ” );
}
} catch ( Exception e ) {
System.err.println( prefix + “ , :” + e.getMessage() );
}
}
/**
*
*/
static void deleteNodeByNoAuthentication() throws Exception {
String prefix = “[ ]“;
try {
System.out.println( prefix + “ :” + PATH_DEL );
zkClient = new ZkClient( SERVER_LIST, 50000);
if( zkClient.exists( PATH_DEL ) ){
zkClient.delete( PATH_DEL );
System.out.println( prefix + “ ” );
}
} catch ( Exception e ) {
System.err.println( prefix + “ , :” + e.getMessage() );
}
}
/**
*
*/
static void deleteNodeByBadAuthentication() throws Exception {
String prefix = “[ ]“;
try {
System.out.println( prefix + “ :” + PATH_DEL );
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, badAuthentication.getBytes() );
if( zkClient.exists( PATH_DEL ) ){
zkClient.delete( PATH_DEL );
System.out.println( prefix + “ ” );
}
} catch ( Exception e ) {
System.err.println( prefix + “ , :” + e.getMessage() );
}
}
/**
*
*/
static void deleteNodeByCorrectAuthentication() throws Exception {
String prefix = “[ ]“;
try {
System.out.println( prefix + “ :” + PATH_DEL );
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, correctAuthentication.getBytes() );
if( zkClient.exists( PATH_DEL ) ){
zkClient.delete( PATH_DEL );
System.out.println( prefix + “ ” );
}
} catch ( Exception e ) {
System.out.println( prefix + “ , :” + e.getMessage() );
}
}
/**
*
*/
static void deleteParent() throws Exception {
try {
zkClient = new ZkClient( SERVER_LIST, 50000);
zkClient.addAuthInfo( authentication_type, correctAuthentication.getBytes() );
if( zkClient.exists( PATH ) ){
zkClient.delete( PATH );
}
} catch ( Exception e ) {
e.printStackTrace();
}
}
@Override
public void process( WatchedEvent event ) {
// TODO Auto-generated method stub
}
}
ソリューション二、zookeeperのAuthentication Providerを拡張し、内部の他のシステムAと通信し、システムAからいくつかの情報を取得して権限を判断する.この案は大体このようです.1.AシステムにはIPとappNameのデータがあります.2.このデータをZKサーバで一部キャッシュし、タイミングでキャッシュ更新します.3.クライアントがサーバに対して要求を開始するたびに、クライアントipを取得して照会し、アプリNameに対応する権限があるかどうかを判断する.指定されたipは指定/appNameznodeのみ操作できます.4.その他の災害対策.
個人は2つの案を比較します.1.方案は方案の2より、ユーザーのコントロールが大きいので、オンラインでも日常でも、テストはアプリケーション開発者が自分で決定して権限を開くことができます.(案1の利点)2.案2は、使いやすさが強く、ユーザーの使用と権限がほぼ一致しています.(案二の優勢)3.案二より純潔である.zkはもともと1つの底の部品であるべきだと思っています.彼に他の上の階のもう一つのシステムに依存させます.権限の制御精度はシステムAにおける情報の正確さに依存する.(案一のメリット)
加えて、プログラムを添付します.3台のZKサーバ:8コアJDK 1.6.0-06 4台のzkクライアントマシン:5コアJDK 1.6.0-21テストシーン:800人の発表者、800個のパスに対応しています.各path 3人の予約者、合計2400人の予約者です.発表者はデータを発表して、購読者に通知します.結論:権限制御はzkのTPSに一定の影響を与えているが、まだ高い水準にある(1.3 w+)