7 Replies Latest reply: Feb 12, 2010 6:37 AM by Marek Goldmann RSS

CirrAS - the real back end appliance

Michael Neale Expert

On this page here: http://community.jboss.org/wiki/StormGrindCirrASAppliances we have a "back end appliance" that is an app server + management. I guess I would call that a "application appliance" or something.

 

What I mean is that should we (can we?) have a dedicated set of database appliances (as in RDBMS, leave Infinispan etc for another day) - say for Postgresql and MySQL?

 

In the management-appliance there is Postgressql already - so it wouldn't be too onerous to have an appliance dedicated to it, not for management but for the app itself (similar for MySQL, ideally, but can pick one to start with).


Some thoughts:

 

  • No need to have database share an instance with an app server
    • will always have them separate, but we may have multiple apps sharing the one db process in future...
  • Would be nice to have option to start up a db appliance as a slave for replication to a specified master (is this possible? or need to change config on master?)

 

Thoughts ?

  • 1. Re: CirrAS - the real back end appliance
    Marek Goldmann Master

    On this page here: http://community.jboss.org/wiki/StormGrindCirrASAppliances we have a "back end appliance" that is an app server + management. I guess I would call that a "application appliance" or something.

    The management you specified that exists on back-end is only an agent to collect data and send it to server (management appliance). I would leave the name as it is right now because it could add confusion. Of course we can create other appliances too that could satisfy you.

    What I mean is that should we (can we?) have a dedicated set of database appliances (as in RDBMS, leave Infinispan etc for another day) - say for Postgresql and MySQL?The main problem with database appliances in the Cloud right now is no unified way to store data. EC2 is ephemereal, VMware cloud is not. So, we should don't care

    We can make a database appliances set. Just a few questions:

    1. Do we care whenever the data is ephemeral or not?
    2. Do we assume user will log in to database appliance instance and create required databases?
    3. How about security? Do we want to restrict access to database to selected instances?

    In the management-appliance there is Postgressql already - so it wouldn't be too onerous to have an appliance dedicated to it, not for management but for the app itself (similar for MySQL, ideally, but can pick one to start with).

    We had in JBoss Cloud PostGIS appliance. We could recreate that, but I would put this appliance into StormFolio (not in CirrAS – not everybody wants to have a database appliance).

     

     

    • No need to have database share an instance with an app server
      • will always have them separate, but we may have multiple apps sharing the one db process in future...

    Agreed. As I said above we cn recreate it. The main things behind putting RHQ and PostgreSQL on one instance were:

    1. Simple deployment,
    2. RHQ and PostgreSQL is a whole so I decided to put it on one appliance.
    3. Costs – having an additional almost iddle instance is not cost effective.

     

    We can create separate appliance definitions for database and PostgreSQL and merge them of course.

    • Would be nice to have option to start up a db appliance as a slave for replication to a specified master (is this possible? or need to change config on master?)

    We should be able to do this, probably this will imply some changes in configuration.

  • 2. Re: CirrAS - the real back end appliance
    Michael Neale Expert

    OK - so I guess the name for the new one would be "database-appliance" ? I think the 'back end' name currently used for middlware is already confusing though? one day may want to reconsider the name.

     

    To answer some other questions:

    We can make a database appliances set. Just a few questions:

    1. Do we care whenever the data is ephemeral or not?
    2. Do we assume user will log in to database appliance instance and create required databases?
    3. How about security? Do we want to restrict access to database to selected instances?

     

    1: must not be ephemeral - yes, this is the data store. So for EC2 - that means using EBS, no question. For other clouds, that means ensuring a backup scheme has been selected (neither of these is part of deltacloud now AFAIK - so a problem there? might be able to use jclouds instead)

    2: Yes - well not so much the end user as the system. The workflow I expect is that when an application version is deployed, there are some "migration tasks" one of which is to run DDL scripts on the database. Another would be to set up the "table space" of the app is brand new.

    3: yes - would want to restrict it to certain app servers (possibly)

     

    We had in JBoss Cloud PostGIS appliance. We could recreate that, but I would put this appliance into StormFolio (not in CirrAS – not everybody wants to have a database appliance).

    Right - ok yes this should be part of StormFolio - wasn't sure what that was for, now I know !

     

    Agreed. As I said above we cn recreate it. The main things behind putting RHQ and PostgreSQL on one instance were:

    1. Simple deployment,
    2. RHQ and PostgreSQL is a whole so I decided to put it on one appliance.
    3. Costs – having an additional almost iddle instance is not cost effective.

    Right - yes it is fine having a dedicated management appliance - I imagine that could span a whole lot of apps anyway.

    but yes, having a dedicated DB appliance is necessary - and we would avoid having "almost idle"instances in a PaaS cloud by multi tenanting "lite" apps together, even for their database.

     

    Hope that makes sense.

     

    In future, I suspect EBS like features for files will be on most clouds, and make its way into the cloud apis, so appliances will need to take that into account when that is the case (and in EC2's case, I think we have to use EBS if we want data to not suddently disappear).

  • 3. Re: CirrAS - the real back end appliance
    Marek Goldmann Master

    OK - so I guess the name for the new one would be "database-appliance" ? I think the 'back end' name currently used for middlware is already confusing though? one day may want to reconsider the name.

    What kind of database engine we want to use? PostgreSQL? MySQL? I would say we create a postgresql appliance and (maybe) a mysql appliance. Or we choose for example PostgreSQL and use database appliance name?

    1: must not be ephemeral - yes, this is the data store. So for EC2 - that means using EBS, no question. For other clouds, that means ensuring a backup scheme has been selected (neither of these is part of deltacloud now AFAIK - so a problem there? might be able to use jclouds instead)

    2: Yes - well not so much the end user as the system. The workflow I expect is that when an application version is deployed, there are some "migration tasks" one of which is to run DDL scripts on the database. Another would be to set up the "table space" of the app is brand new.

    3: yes - would want to restrict it to certain app servers (possibly)

    1. I think we can use this for EC2 but I haven't looked into it yet.
    2. OK.
    3. How? Firewall management built into CT? Database management built into CT?
    Right - yes it is fine having a dedicated management appliance - I imagine that could span a whole lot of apps anyway.

    but yes, having a dedicated DB appliance is necessary - and we would avoid having "almost idle"instances in a PaaS cloud by multi tenanting "lite" apps together, even for their database.

     

    Hope that makes sense.

    Sure, agreed! I'll post later a diagram with my view of the arch we need to setup.

    In future, I suspect EBS like features for files will be on most clouds, and make its way into the cloud apis, so appliances will need to take that into account when that is the case (and in EC2's case, I think we have to use EBS if we want data to not suddently disappear).

     

    As I pointed out above we can use EBS as root device for images we want to store state.

  • 4. Re: CirrAS - the real back end appliance
    Michael Neale Expert

    I think we can start with postgresql appliance - mysql can come later?

     

    Yes - eventually CT could setup firewall access for the different running appliances. CT itself would run on a management appliance - but that management appliance would not be specific to any cluster or grouping of servers of course.

  • 5. Re: CirrAS - the real back end appliance
    Michael Neale Expert
    For some reason I was forgetting about the management appliance - so the management appliance - there would be one of those for many clusters/apps right? (ie you only really need one in a "cloud" installation?)
  • 6. Re: CirrAS - the real back end appliance
    Marek Goldmann Master
    I think we can start with postgresql appliance - mysql can come later?

    +1

    Yes - eventually CT could setup firewall access for the different running appliances. CT itself would run on a management appliance - but that management appliance would not be specific to any cluster or grouping of servers of course.

    +1 also

  • 7. Re: CirrAS - the real back end appliance
    Marek Goldmann Master
    For some reason I was forgetting about the management appliance - so the management appliance - there would be one of those for many clusters/apps right? (ie you only really need one in a "cloud" installation?)

    Exactly – one management appliance per deployment (multiple clusters/apps). But we need to think about a failover in case it dies. Currently there is no support for this I think, but haven't tested terminating management appliance and starting a new instance. I'm in the process of rewriting "a bit" management service – I can take a look on this. Created a JIRA issue to track this: https://jira.jboss.org/jira/browse/CIRRAS-26