zetcd は、ZooKeeper へのアプリケーションの依存関係を削除する方法を解決します。

分散システムは通常、連携するために調停システムに依存します。通常、このようなシステムは調停を使用して、スプリット ブレインを回避するために情報の正確な送信を保証します。このようなシステムは、十分な設計の余地と引き換えに汎用性を犠牲にしており、これは実装の急増によって明らかに実証されています。 chubby、ZooKeeper、etcd、consul など、そのようなシステムはたくさんあります。これらのシステムの概念とプロトコルは異なりますが、いずれも同様のキー値ベースの分散アービトレーションを提供します。 etcd を分散システムの最も注目度の高い基本コンポーネントにする計画の一環として、etcd チームは新しいエージェント zetcd を開発しました。これにより、etcd クラスターは ZooKeeper サービス リクエストを変更せずに使用できるようになります。

ZooKeeper は、調停ソフトウェアの最初のオープンソース実装であり、これにより、多くの分散システムで推奨されるバックエンドになりました。理論的には、これらのシステムは etcd と互換性があるはずですが、歴史的な理由により、そうではありません。etcd クラスターは ZooKeeper を置き換えることができず、そのデータ モデルとクライアント プロトコルは ZooKeeper アプリケーションと互換性がありません。またその逆も同様です。システムがすでに運用されている場合、それを新しいバックエンドに接続して新たな複雑さを導入する動機はほとんどありません。

幸いなことに、etcd v3 API は、標準プロキシ zetcd を介して ZooKeeper データ モデルのシミュレーション サポートを実装する準備をしています。zetcd は、etcd チームによって開発された新しいオープン ソース プロジェクトです。本日、zetcd の最初のベータ版 v0 が公開されました。 0.1 のリリースの目標は、実稼働システムで zetcd システムを管理および展開することです。

zetcd エージェントは etcd クラスターの前にデプロイされ、シミュレートされた ZooKeeper クライアント ポートを提供し、ZooKeeper アプリケーションが上位層で etcd をネイティブに呼び出せるようにします。一般に、zetcd は ZooKeeper クライアント リクエストを受け入れ、それらを etcd のデータ モデルと API に変換し、リクエストを etcd に転送し、クライアントが理解できる方法で戻り情報を転送します。 zetcd のパフォーマンスは ZooKeeper に匹敵し、ZooKeeper クラスターと etcd 間の管理と操作の複雑さを簡素化します。この記事では、zetcd の使用方法、zetcd の仕組み、およびパフォーマンス ベンチマークについて説明します。

zetcd を実行するために必要なものは、go コンパイラー、インターネットから入手したソース コード、および etcd を実行できるシステムです。次の例は、zetcd ソース コードを取得し、zetcd 上で ZooKeeper コマンドを実行する方法を示しています。 etcd と zetcd は両方とも開発ブランチに基づいて構築されているため、運用環境でこれを行うことはお勧めできません。これは、その使用方法を説明するための簡単な例にすぎません。

まず、etcd および zetcd のソース コードを取得し、バイナリ コードにコンパイルします。

次に、etcd を実行し、zetcd を etcd クライアント サーバーに接続します:

サブスクリプションを追加してキーを作成して、zetd を試してください:

概念的には、上記の例で単一の etcd インスタンスへの zetcd のレイヤーの追加が完了します。

詳しく説明すると、zetcd は ZooKeeper のデータ モデルを適応された etcd API に変換します。キー検索の場合、zetcd は ZooKeeper 階層ディレクトリを etcd のフラット バイナリ キースペースに変換します。メタデータを管理するために、etcd バックエンドに書き込むときに、zetcd はメモリ レベルのトランザクションを利用して、情報を ZooKeeper znode 情報に安全かつアトミックに更新します。

ZooKeeper はディレクトリ モード (getChildren) でキーをリストしますが、etcd は間隔 (範囲) モードを使用します。次の図は、ディレクトリ形式でのリストを効果的にサポートするために、zetcd が etcd でキーをエンコードする方法を説明しています。 etcd 内のすべての zetcd キーには、完全なディレクトリ名を含むプレフィックスが付いています (たとえば、「/」と「/abc」はそれぞれ深さ 0 と 1 を表します)。ディレクトリを一覧表示するには、zetcd はプレフィックス付き範囲リクエスト (["/zk/key/002/abc/"、"/zk/key/002/abc0" など) を発行して、ディレクトリの深さとパスを満た​​すディレクトリを一覧表示します。 . /abc/ の下にあるすべてのキー。深さの制限はディレクトリ自体にのみ適用されます。zetcd がパスのみを使用し、深さは使用しない場合、etcd はこのディレクトリ内のすべてのキーを返し、zetcd は結果を破棄します。それ以外の場合は、このディレクトリ内のキーのみが返されます。

各 ZooKeeper キーには、ZNode 内にいくつかのメタデータ (キー調整、バージョン、権限など) が含まれています。 etcd にも各キーのメタデータがありますが、ZNode よりもはるかに単純です。たとえば、ディレクトリがないため、Subversion がありません。etcd はロールベースの認証メカニズムを使用しているため、ACL がなく、実際のクロックはありません。は範囲外です。タイムスタンプはありません。これらの追加のメタデータは、完全な ZNode を記述するために対応するキーにマップされます。メタデータを変更する場合、zetcd はメモリ レベルのソフト トランザクションを使用してキーのサブセットを自動的に更新し、高価なロック メカニズムを使用せずに ZNode の一貫性を維持できるようにします。

さらに、zetcd は、認可された ZooKeeper サーバーを使用して動的検証を実行できます。比較のために、zetcd は etcd と外部 ZooKeeper サーバーの両方に接続できます。クライアントがこのモードで zetcd へのリクエストを開始すると、リクエストは zetcd と ZooKeeper サーバーの両方に転送されます。 2 つのサーバーから応答されたデータが矛盾している場合、zetcd はこの応答に対して警告のフラグを立てます。

由于数据的转换以及额外的网络开销，也许很容易觉得这样的模拟不切实际。尽管对于ZooKeeper或者etcd集群来说，zetcd有额外的花销，但是它仍然有一个优势，即某些etcd应用安装完毕后仍然需要ZooKeeper来协调的场景。例如，早期用户报告称在zetcd里通过etcd的TLS加密流量比一个类似的经典ZooKeeper配置更简单。在这些场景中，支持同一种ZooKeeper协议所带来的简单可靠性比性能更重要一些。 跟etcd性能工具的接口及报告形式类似，zetcd命令行工具zkboom可以用来判断一个zetcd的性能基准是否满足要求。其它ZooKeeper性能工具应该也可以用在zetcd；zkboom为用户提供了便利，我们不妨试试用它来做下创建key的测试：

go get github.com/coreos/zetcd/cmd/zkboom 
zkboom --conns=50 --total=10000 --endpoints=localhost:2181 create

zetcd应当可以为小负载提供充分的性能保障。一个简单两节点配置的延迟基准表明zetcd是可以承受大量请求的。具体配置为两台Linux服务器通过一个千兆交换机互联，其中一台设备在RAID磁盘配置上运行代理和和服务端，另外一台设备用于产生客户请求。zkbook通过创建一个空的key存储，然后从中读取128Kbytes的键值对来进行测量。用户请求被限制在每秒2500个请求，然后逐渐增加并发客户端数量。ZooKeeper 3.4.10和etcd结果对比见下图。

下图揭示了zetcd客户端并发数与创建key的平均延迟之间的关系。由于etcd在延迟上比ZooKeeper要有5-35ms的优势，zetcd有足够余地处理由于额外负载和网络跳转造成的延迟。比起ZooKeeper，zetcd代理始终还是存在20ms左右的差距，但是从处理2500请求的吞吐量数据来看，并没有出现队列堵塞。一种对zetcd写比较慢的解释是，与读不一样，由于数据模型上存在差异，所以在每个ZooKeeper key写时需要写多个key。

下图揭示了zetcd客户端并发数与key取值的平均延迟之间的关系。由于ZooKeeper的取值延迟比etcd要快那么2ms左右，想要zetcd提供数据的速度快过ZooKeeper的话恐怕还得依赖于etcd本身性能的进一步提升。然而，尽管zetcd需要从etcd请求额外的key来模拟Zookeeper znode的元数据，zetcd的命中延迟在等待etcd key提取数据方面只增加了大概1.5ms。zetcd在key的数据提取操作方面仅需一次往返，因为读请求会被打包到一个etcd事务中。

zetcd承诺上述性能基准测试的结果是合理的，在可接受的延迟情况下，可以轻松支撑每秒上千个操作。以上模拟对于Mesos，Kafka和Drill替代ZooKeeper提供了一个替代选择。但是对于zetcd本身来说性能方面仍有不少的提升空间。与此同时测试更多的ZooKeeper应用也会进一步推动zetcd成为ZooKeeper服务器的替代品。

zetcd从去年十月开始在开源社区发行，最近刚发布第一个版本：zetcd v0.0.1。尽管是第一个beta发行版，但是已经为未来生产系统提供稳定管理和部署。如果跟etcd配合起来使用，运行zetcd的系统将会一套自驱动的“ZooKeeper”集群，它可以自动后台升级，备份和TLS管理。

etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。

以上がzetcd は、ZooKeeper へのアプリケーションの依存関係を削除する方法を解決します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。