Adding Dev ---------- Forwarded message ---------- From: Pubudu Gunatilaka <[email protected]> Date: Fri, Feb 24, 2017 at 6:12 PM Subject: Re: [Dev] Traffic Manager HA deployment on DC/OS To: JOSE MARIA ALVAREZ FERNANDEZ < [email protected]>
Hi Jose, Yes, it is true that every TM node needs a separate database schema to store message broker related data. Normally we don't recommend H2 database for a production environment. But if you do not have a way to provision separate databases for TM nodes, you can try to use the H2 database. The data stored in the database is not useful if the TM node comes back after a shutdown. In other words, if the TM container goes down and comes back, they do not need the previous data to function. If you are using H2, please make sure you run load tests to verify the TM node's functionality with H2. Another option I can think is to use 2 applications in DC/OS for TM nodes. Thank you! On Thu, Feb 23, 2017 at 10:45 PM, JOSE MARIA ALVAREZ FERNANDEZ < [email protected]> wrote: > Hi all, > > As you may know, we are implementing WSO2 in El Corte Ingles, and we are > trying to fit Traffic Manager in our architecture, based on DC/OS and > containers. We would like to know which approach you think it may be better > for the Traffic Manager component. As we are in a PaaS system, we would > like to be able to scale this system out without problems. > > a) It is our understanding that we have to create a different database > schema for every TM instance that we run. We would like to know if it is > possible to run this without having to create a new schema for every > component (that is, share the same schema). If we create a new schema, that > would force us to differentiate the component at DC/OS level, giving them > different configurations for different Traffic Manager instances. > > b) If that is not possible, we would like to know if it is possible to run > TM with H2 in memory. As there is nothing that should be persisted in the > TM schema, we thought that could be possible. > > If none of the options are viable, what deployment schema would be the > best for this component, taking into account that we would like to be > active/active (being able to scale out)? > > Thank you very much for your help and comments, > > Jose Maria. > > > www.elcorteingles.es > > ------------------------------------------------------------ > ------------------------------------------------------- > > Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede > contener información confidencial, siendo para uso exclusivo del > destinatario, quedando prohibida su divulgación copia o distribución a > terceros sin la autorización expresa del remitente. Si Vd. ha recibido > este mensaje erróneamente, se ruega lo notifique al remitente y > proceda a su borrado. > Gracias por su colaboración. > > This message (including any attachments) may contain confidential > information. It is intended for use by the recipient only. Any > dissemination, copying or distribution to third parties without the > express consent of the sender is strictly prohibited. If you have > received this message in error, please delete it immediately and > notify the sender. > Thank you for your collaboration. > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Pubudu Gunatilaka* Committer and PMC Member - Apache Stratos Software Engineer WSO2, Inc.: http://wso2.com mobile : +94774078049 <%2B94772207163> -- *Pubudu Gunatilaka* Committer and PMC Member - Apache Stratos Software Engineer WSO2, Inc.: http://wso2.com mobile : +94774078049 <%2B94772207163>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
