1

5 つの Riak-CS ノードの仮想化されたクラスターがあります。支柱は最初のノードに取り付けられます。これらのノードは、Nginx リバース プロキシの背後にあります。

boto ライブラリを使用している Python スクリプトを使用して JPG ファイルをアップロードすると、正常に動作します。

cf=OrdinaryCallingFormat()
conn=S3Connection(aws_access_key_id=apikey,aws_secret_access_key=secretkey,is_secure=False,host=s3Host,port=s3Port,calling_format=cf)
b = conn.get_bucket(bucketName)
k = b.new_key(fileName)
k.set_contents_from_filename(fileName, policy='public-read')

ただし、このようにすると、ACL がパブリックに設定されない場合もありますが、そうなる場合もあります (注: 最初にファイルをアップロードしてから ACL を設定しています)。

cf=OrdinaryCallingFormat()
conn=S3Connection(aws_access_key_id=apikey,aws_secret_access_key=secretkey,is_secure=False,host=s3Host,port=s3Port,calling_format=cf)
b = conn.get_bucket(bucketName)
k = b.new_key(fileName)
k.set_contents_from_filename(fileName)
k.set_acl('public-read')

Nginx のログ ファイルを確認したところ、最初のケースでは次のようになっていることがわかりました。

"HEAD /test/ HTTP/1.1" 200 0 "-" "Boto/2.29.1 Python/2.7.3 Windows/7"
"PUT /test/1.jpg HTTP/1.1" 200 25 "-" "Boto/2.29.1 Python/2.7.3 Windows/7"

2 番目のケースでは、次のようになります。

"HEAD /test/ HTTP/1.1" 200 0 "-" "Boto/2.29.1 Python/2.7.3 Windows/7"
"PUT /test/1.jpg HTTP/1.1" 200 25 "-" "Boto/2.29.1 Python/2.7.3 Windows/7"
"PUT /test/1.jpg?acl HTTP/1.1" 200 0 "-" "Boto/2.29.1 Python/2.7.3 Windows/7"

どちらも期待できます。

「s3cmd info s3://test/1.jpg」を使用して、ファイルの ACL を調べています。PUT acl が送信される Riak-CS サーバーによっては、ファイルがパブリックに変更される場合とそうでない場合があります。スクリプトを実行しているマシンから出てくるネットワーク トラフィックを確認しました。新しい ACL を PUT するコマンドは、失敗の成功に関係なく毎回まったく同じです。NGINX を介したメッセージも毎回まったく同じであり、ACL をパブリックに更新しない場合でも 200 を返します。

アップロード中に各ノードの Riak-CS ログ ファイルを監視しましたが、5 つの異なるアップロード シナリオのうち 2 つのシナリオでのみ発生しているようです。詳細は次のとおりです。

ファイルはノード 4 で PUT され、ACL はノード 3 で PUT されます。ファイルの ACL (S3Cmd Info) がノード 1 に対して実行され、結果が成功である場合、ACL にはパブリック アクセス セットが設定されています。その他の事例はこちら ->

Obj PUT Node: 4  ACL PUT Node: 3  Read Node: 1 = Success
Obj PUT Node: 3  ACL PUT Node: 2  Read Node: 5 = Success
Obj PUT Node: 2  ACL PUT Node: 1  Read Node: 4 = Fail
Obj PUT Node: 1  ACL PUT Node: 5  Read Node: 3 = Success
Obj PUT Node: 5  ACL PUT Node: 4  Read Node: 2 = Fail
Obj PUT Node: 4  ACL PUT Node: 3  Read Node: 1 = Success
Obj PUT Node: 3  ACL PUT Node: 2  Read Node: 5 = Success
Obj PUT Node: 2  ACL PUT Node: 1  Read Node: 4 = Fail
Obj PUT Node: 1  ACL PUT Node: 5  Read Node: 3 = Success
Obj PUT Node: 5  ACL PUT Node: 4  Read Node: 2 = Fail

ご覧のとおり、ACL が「固定」される場合と、そうでない場合があります。すべてのノード、特に 1 と 4 の構成を確認しましたが、問題は見当たりません。

なぜこれがうまくいかないのか、またはここで何が起こっているのかを調査し続ける方法を知っている人はいますか?

4

1 に答える 1

2

これは、Riak CS [1] のバグと、サーバー間のクロックが同期されていないことが原因です。詳細なバグの説明については、[1] を参照してください。

現在の回避策は、サーバー クロックを同期することです。100ミリ秒単位で同期できれば可能性は低いと思います(どうやらクライアントでのPUT ObjectとPUT Aclの間隔や、クライアントとriak cs間のネットワーク遅延にもよるらしい)。うまくいかない場合は、クライアント コードの PUT オブジェクトの後に待機を追加してください:P

詳細な成功/失敗パターン分析をありがとう、マーク。それは迅速なバグの特定につながりました:)

[1] https://github.com/basho/riak_cs/issues/879

于 2014-06-07T00:26:09.973 に答える