cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Boxenhorn <>
Subject Re: Multi-tenancy, and authentication and authorization
Date Thu, 20 Jan 2011 12:05:40 GMT
I have added my comments to this issue:

Good luck!

On Thu, Jan 20, 2011 at 1:53 PM, indika kumara <>wrote:

> Thanks David.... We decided to do it at our client-side as the initial
> implementation. I will investigate the approaches for supporting the fine
> grained control of the resources consumed by a sever, tenant, and CF.
> Thanks,
> Indika
> On Thu, Jan 20, 2011 at 3:20 PM, David Boxenhorn <>wrote:
>> As far as I can tell, if Cassandra supports three levels of configuration
>> (server, keyspace, column family) we can support multi-tenancy. It is
>> trivial to give each tenant their own keyspace (e.g. just use the tenant's
>> id as the keyspace name) and let them go wild. (Any out-of-bounds behavior
>> on the CF level will be stopped at the keyspace and server level before
>> doing any damage.)
>> I don't think Cassandra needs to know about end-users. From Cassandra's
>> point of view the tenant is the user.
>> On Thu, Jan 20, 2011 at 7:00 AM, indika kumara <>wrote:
>>> +1   Are there JIRAs for these requirements? I would like to contribute
>>> from my capacity.
>>> As per my understanding, to support some muti-tenant models, it is needed
>>> to qualified keyspaces' names, Cfs' names, etc. with the tenant namespace
>>> (or id). The easiest way to do this would be to modify corresponding
>>> constructs transparently. I tought of a stage (optional and configurable)
>>> prior to authorization. Is there any better solutions? I appreciate the
>>> community's suggestions.
>>> Moreover, It is needed to send the tenant NS(id) with the user
>>> credentials (A users belongs to this tenant (org.)). For that purpose, I
>>> thought of using the user credentials in the AuthenticationRequest. s there
>>> any better solution?
>>> I would like to have a MT support at the Cassandra level which is
>>> optional and configurable.
>>> Thanks,
>>> Indika
>>> On Wed, Jan 19, 2011 at 7:40 PM, David Boxenhorn <>wrote:
>>>> Yes, the way I see it - and it becomes even more necessary for a
>>>> multi-tenant configuration - there should be completely separate
>>>> configurations for applications and for servers.
>>>> - Application configuration is based on data and usage characteristics
>>>> of your application.
>>>> - Server configuration is based on the specific hardware limitations of
>>>> the server.
>>>> Obviously, server limitations take priority over application
>>>> configuration.
>>>> Assuming that each tenant in a multi-tenant environment gets one
>>>> keyspace, you would also want to enforce limitations based on keyspace
>>>> (which correspond to parameters that the tenant payed for).
>>>> So now we have three levels:
>>>> 1. Server configuration (top priority)
>>>> 2. Keyspace configuration (payed-for service - second priority)
>>>> 3. Column family configuration (configuration provided by tenant - third
>>>> priority)
>>>> On Wed, Jan 19, 2011 at 3:15 PM, indika kumara <>wrote:
>>>>> As the actual problem is mostly related to the number of CFs in the
>>>>> system (may be number of the columns), I still believe that supporting
>>>>> exposing the Cassandra ‘as-is’ to a tenant is doable and suitable
>>>>> need some fixes.  That multi-tenancy model allows a tenant to use the
>>>>> programming model of the Cassandra ‘as-is’, enabling the seamless
>>>>> of an application that uses the Cassandra into the cloud. Moreover, In
>>>>> to support different SLA requirements of different tenants, the
>>>>> configurability of keyspaces, cfs, etc., per tenant may be critical.
>>>>> However, there are trade-offs among usability, memory consumption, and
>>>>> performance. I believe that it is important to consider the SLA requirements
>>>>> of different tenants when deciding the strategies for controlling resource
>>>>> consumption.
>>>>> I like to the idea of system-wide parameters for controlling resource
>>>>> usage. I believe that the tenant-specific parameters are equally important.
>>>>> There are resources, and each tenant can claim a portion of them based
>>>>> SLA. For instance, if there is a threshold on the number of columns per
>>>>> node, it should be able to decide how many columns a particular tenant
>>>>> have.  It allows selecting a suitable Cassandra cluster for a tenant
>>>>> on his or her SLA. I believe the capability to configure resource
>>>>> controlling parameters per keyspace would be important to support a keyspace
>>>>> per tenant model. Furthermore, In order to maximize the resource sharing
>>>>> among tenants, a threshold (on a resource) per keyspace should not be
a hard
>>>>> limit. Rather, it should be oscillated between a hard minimum and a maximum.
>>>>> For example, if a particular tenant needs more resources at a given time,
>>>>> or she should be possible to borrow from the others up to the maximum.
>>>>> threshold is only considered when a tenant is assigned to a cluster -
>>>>> remaining resources of a cluster should be equal or higher than the resource
>>>>> limit of the tenant. It may need to spread a single keyspace across multiple
>>>>> clusters; especially when there are no enough resources in a single
>>>>> cluster.
>>>>> I believe that it would be better to have a flexibility to change
>>>>> seamlessly multi-tenancy implementation models such as the Cassadra ‘as-is’,
>>>>> the keyspace per tenant model, a keyspace for all tenants, and so on.
>>>>> on what I have learnt, each model requires adding tenant id (name space)
>>>>> a keyspace’s name or cf’s name or raw key, or column’s name.  Would
it be
>>>>> better to have a kind of pluggable handler that can access those resources
>>>>> prior to doing the actual operation so that the required changes can
>>>>> done? May be prior to authorization.
>>>>> Thanks,
>>>>> Indika

View raw message