问题标签 [openstack-swift]

我正在按照教程安装 swift openstacl 对象存储，在最新的步骤中它要求我这样做：------- "curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' url:8080/auth/v1.0" ------ 获取 X-Storage-Url 和 X-Auth-Token ，然后检查我可以通过键入： curl -v -H 'X-Auth-Token:token-from-x-auth-token-above' url-from-x-storage-url-above

有谁知道这样的命令意味着什么？我真的不明白它的规则！我知道这是识别之王，但究竟是什么意思？

谢谢

我正在测试 Swift 的性能。该环境由 1 个 Swift 代理节点和 3 个 Swift 存储节点组成。每个存储节点都有 2GB 的 RAM，并安装在 100GB 的分布上。

首先，吞吐量的结果是可以接受的。经过几天的测试，性能下降了很多。而且我发现存储节点的内存使用率非常高（超过 95%）。

Swift 中是否有任何配置来控制节点的内存使用？还是增加 RAM（等 8GB RAM）的唯一解决方案？具有 8GB RAM 的节点也会内存不足吗？

有没有办法强制过期或撤销 OpenStack Swift 令牌？我正在寻找一些 API 方法来做到这一点。

Bing / Google 搜索没有返回任何有用的信息。

每个人。我安装了 Swift 1.7.4 ，我想向 Swift 添加一个新用户，我该怎么做？我发现在1.4.8版本中，有人说我应该先安装swauth，我注意到Swift api也说选择一种授权方式，所以我必须先安装授权服务？我还发现 proxy-server.conf 文件中有一个 tempauth 中间件，我可以使用它来添加用户吗？如何添加？

即使在直接从文件系统中删除容器和对象之后，Swift 也会在对其执行 GET 命令时列出容器。但是，如果我们尝试使用 DELETE 命令删除容器，则会返回 404: Not Found 错误消息。请解释是否有问题或是否有某种缓存？

假设我使用以下命令在 swift 存储节点上创建了一个容器。

curl -v -X PUT -H 'X-Auth-Token: AUTH_tkf0685272b8f64c80a97727141a64a7ca' http://www.tempwebsite.com:8080/v1/AUTH_test/tempcontainer

如果我签入创建 swift 节点的文件系统，则会在容器文件夹下创建一个新容器。

我现在也可以通过 GET 调用看到这个容器，如下所示：

curl -v -H 'X-Auth-Token: AUTH_tkf0685272b8f64c80a97727141a64a7ca' http://www.tempwebsite.com:8080/v1/AUTH_test/

现在，当我通过 DELETE 调用删除此容器时，如下所示

curl -v -X DELETE -H "X-Auth-Token: AUTH_tkf0685272b8f64c80a97727141a64a7ca" http://www.tempwebsite.com:8080/v1/AUTH_test/tempcontainer

它似乎已被删除，因为当我在删除后进行 GET 调用时，容器不存在并且我得到 404 not found repsonse

但是，文件系统中的容器仍然存在，因为它也是在对象数据文件被转换为墓碑文件的情况下，但这些墓碑文件也不会被删除。（Swift 文档说它们最终会被收割者移除，但是请注意我已经等了超过 4 天，但对象和容器仍然存在。）

请建议。

我有一些文件存储在 OpenStack Swift（或任何其他存储系统）上。我的 django 应用程序提供了基于浏览器的 GUI 供用户从 Swift 后端下载这些文件：

我已经测试了静态文件下载为：

我的问题是：

(1) 我可以从下载视图下载文件，但下载的文件大小始终为 1k。这里有什么问题？

(2) 我仍然不知道如何提供存储在其他对象存储后端（如 OpenStack Swift）上的动态文件下载？

我安装了一个快速服务，并试图了解处理并发请求的能力。所以我在 Java 中创建了大量线程，并通过RestFUL API发送

毫不奇怪，当请求数量攀升时，程序开始抛出异常。

引起：java.net.ConnectException：连接超时：在 java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:69) 在 java.net.AbstractPlainSocketImpl.doConnect( AbstractPlainSocketImpl.java:339) 在 java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) 在 java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) 在 java.net.PlainSocketImpl.connect(PlainSocketImpl.java:157) ) 在 java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) 在 java.net.Socket.connect(Socket.java:579) 在 java.net.Socket.connect(Socket.java:528) 在 sun.net .NetworkClient.doConnect(NetworkClient.java:180) 在 sun.net.www.http.HttpClient.openServer(HttpClient.java:378) 在 sun.net.www.http.HttpClient。openServer(HttpClient.java:473) 在 sun.net.www.http.HttpClient.(HttpClient.java:203)

但是谁能告诉我这是怎么time out回事？我很好奇 SWIFT 如何处理这些请求。是通过对请求进行排队，并且因为队列中的请求太多并且等待太长时间并且它只是被从队列中踢出？如果这成立，是否意味着它是一种处理请求的异步机制？

让它更有趣，有时我也会Connection refused出错Error writing request body to server，这会是另一个可以用机制解释的观察结果吗？

谢谢。

We are using the jclouds library for connection to OpenStack Swift (grizzly) cloud storage, and are running into the following issue: https://issues.apache.org/jira/browse/JCLOUDS-155

We are using Apache web front for the swift proxy as defined here: http://docs.openstack.org/developer/swift/apache_deployment_guide.html

Essentially the issue is that the Apache web front (using mod-wsgi) returns a lower case header (x-storage-url), whereas jClouds is expecting it to be X-Storage-URL (case-sensitive).

So the jClouds is being case-sensitive. When it shouldn't be. Is there anything we can do to work around this, while someone from the jClouds community fixes this issue?

在swift中，一个容器可以容纳多少个文件，这有什么限制吗？我试过谷歌这个问题，但没有得到答案，求助！