cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: [REVIEW] OpenStack Swift as Object Storage Service
Date Fri, 14 Mar 2014 20:56:56 GMT
I agree. It's not immediately clear to me why there's a prerequisite
that the traffic for both mgmt servers and swift have to go to the
same IP. It also eliminates the use of v1.0 and v1 for other purposes,
as its very common for REST API routes to start with something like
that (say the CS mgmt server itself rolls a REST API one day).

On Fri, Mar 14, 2014 at 1:39 PM, Edison Su <Edison.su@citrix.com> wrote:
> What I am trying to say is the public domain name for CloudStack mgt server and cloud
storage(either swift and S3) can be different. For example, the cloudstack mgt server can
have a domain name, like your-company.com, which mapping to a pubic ip address @ 52.53.53.55,
while cloud storage can have a domain name, like, cloud-storage.your-company.com, which mapping
to public ip address @52.53.53.54. With different domain for different service, each service
can scale and control differently.
> The client(browser) can call different domains, as most modern browsers supporting Cross-origin
resource sharing now.
> The workflow will like this:
>
> 1.       Swift javascript client calls cloudstack mgt server api(e.g. listswfitcmd) to
get the public domain of swift service and also get auth info. In your particular case, both
public domain of swift service and cloudstack mgt server are the same.
>
> 2.       Swift javascript client calls public domain of swift service(returned by above
step 1) for all the swift related operations.
> If we support above procedure, then it should be easy to add the support for AWS S3,
or any other public cloud storage.
>
>
> From: williamstevens@gmail.com [mailto:williamstevens@gmail.com] On Behalf Of Will Stevens
> Sent: Thursday, March 13, 2014 7:16 PM
> To: Edison Su
> Cc: dev@cloudstack.apache.org; David Nalley <david@gnsa.us> (david@gnsa.us)
> Subject: Re: [REVIEW] OpenStack Swift as Object Storage Service
>
> Lets say that we have the following setup to help clarify how this all works.
>
> CloudStack Management server is on: 10.10.10.2:8080<http://10.10.10.2:8080>
> Swift Proxy servers are on: 10.10.10.3:8080<http://10.10.10.3:8080>, 10.10.10.4:8080<http://10.10.10.4:8080>,
10.10.10.5:8080<http://10.10.10.5:8080>
> We have a load balancer setup on: 52.53.54.55:80<http://52.53.54.55:80>
> The load balancer is networked to both the Swift cluster and CloudStack.
>
> When you want to connect to CloudStack, you connect to: 52.53.54.55:80<http://52.53.54.55:80>
> You can basically think of that as your CloudStack IP since the load balancer passes
all CloudStack traffic that hits 52.53.54.55:80<http://52.53.54.55:80> directly to CloudStack
(10.10.10.2:8080<http://10.10.10.2:8080>).
>
> To everyone concerned, the IP 52.53.54.55:80<http://52.53.54.55:80> is the CS server
because it behaves like it.
>
> The only URLs that do not go directly to the CloudStack box are URLs that start with
'v1.0' (swift auth urls) and 'v1' (all other swift calls).
>
> In this case we have 3 proxy servers on Swift, so the load balancer will load balance
across the different Swift proxy servers when the URL starts with 'v1.0' or 'v1'.
>
> If we did not do it this way and we setup and endpoint for Swift in CloudStack, then
we would bottleneck all of the traffic to Swift at the CloudStack management server.  The
fact that we have 3 proxy servers would be made irrelevant because all the traffic would be
going through the CloudStack management server first.  This would dramatically reduce the
performance of Swift and would have a dramatic impact on the resources required by the CloudStack
management server.
>
> By splitting the traffic before it gets to either of the services, we can increase the
performance of both of them.
>
> Is that clearer?
>
> Will
>
> On Thu, Mar 13, 2014 at 9:06 PM, Edison Su <Edison.su@citrix.com<mailto:Edison.su@citrix.com>>
wrote:
> The way to talk to swift endpoint, by using haproxy to redirect url request contains
"/v1.0" to swift endpoint, so it assumes, the endpoint of swift is the same as cloudstack
mgt server. Correct me, if I am wrong, I just try to figure how it works.
> But what if the swift endpoint is different from CloudStack mgt server? Take Aws console
as an example, the aws console is console.aws.amazon.com<http://console.aws.amazon.com>,
but the S3 endpoint is s3-console-us-standard.console.aws.amazon.com<http://s3-console-us-standard.console.aws.amazon.com>.
>
> From: williamstevens@gmail.com<mailto:williamstevens@gmail.com> [mailto:williamstevens@gmail.com<mailto:williamstevens@gmail.com>]
On Behalf Of Will Stevens
> Sent: Thursday, March 13, 2014 5:52 PM
> To: Edison Su
> Cc: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>; David Nalley <david@gnsa.us<mailto:david@gnsa.us>>
(david@gnsa.us<mailto:david@gnsa.us>)
> Subject: Re: [REVIEW] OpenStack Swift as Object Storage Service
>
> What are you referring to as the 'v1.0 url hack'?  Bypassing the cloudstack management
server is an intentional design decision to improve performance.  The introduction of a load
balancer in front of the two distinct services to maintain separation of their traffic is
a good thing.
>
> I will review the UI tutorial you sent...
>
> I will check how much work it is to replace PLupload with the jQuery File Upload plugin.
>
> Cheers,
>
> Will
>
> On Thu, Mar 13, 2014 at 8:24 PM, Edison Su <Edison.su@citrix.com<mailto:Edison.su@citrix.com>>
wrote:
> One comment on the "/v1.0" url hack, seems changing mgt server is unavoidable, would
it be easier to  add a new api in cloudstack, which can get the endpoint of swift server and
the auth?
> And the UI change should be put under ui plugin: https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+Plugin+Tutorial,
and also, as David mentioned, plupload is not compatible with Apache license, maybe something
like: https://github.com/blueimp/jQuery-File-Upload, is  better to be used.
>
>

Mime
View raw message