On Tue, May 3, 2016 at 10:57 AM, Erik Jacobs <ejac...@redhat.com> wrote:
> Hi Olga, > > Some responses inline/ > > > Erik M Jacobs, RHCA > Principal Technical Marketing Manager, OpenShift Enterprise > Red Hat, Inc. > Phone: 646.462.3745 > Email: ejac...@redhat.com > AOL Instant Messenger: ejacobsatredhat > Twitter: @ErikonOpen > Freenode: thoraxe > > On Mon, Apr 25, 2016 at 9:34 AM, ABDALA Olga <olga.abd...@solucom.fr> > wrote: > >> Hello all, >> >> >> >> I am done with my *origin advanced installation* (thanks to your useful >> help) which architecture is composed of *4 virtualized servers* (on the >> same network): >> >> - 1 Master >> >> - 2 Nodes >> >> - 1 VM hosting Ansible >> >> >> >> My next steps are to implement/test some use cases with a *three-tier >> App*(each App’s tier being hosted on a different VM): >> >> - The * horizontal scalability*; >> >> - The * load-balancing* of the Nodes : Keep the system running >> even if one of the VMs goes down; >> >> - App’s monitoring using *Origin API*: Allow the Origin API to >> “tell” the App on which VM is hosted each tier. (I still don’t know how to >> test that though…) >> >> >> >> There are some * notions* that are still not clear to me: >> >> - From my web console, how can I know *on which Node has my App >> been deployed*? >> > > If you look in the Browse -> Pods -> select a pod, you should see the node > where the pod is running. > > >> - How can I put *each component of my App* on a *separated Node*? >> >> - How does the “*zones*” concept in origin work? >> > > These two are closely related. > > 1) In your case it sounds like you would want a zone for each tier: > appserver, web server, db > 2) This would require a node with a label of, for example, zone=appserver > 3) When you create your pod (or replication controller, or deployment > config) you would want to specify, via a nodeselector, which zone you want > the pod(s) to land in > > This is not the concept of zones. The point of zones is to spread replicas between different zones in order to improve HA (for instance, define a zone per rack, thereby ensuring that taking down a rack doesn't take down your app that's scaled across multiple zones). This isn't what you want though. And you'd certainly never put a zone in a nodeselector for an RC if you're trying to scale it to multiple zones. For the purpose of separating the tiers of your app, you would still want to use a nodeselector per DC or RC and corresponding node labels. There's no other way to designate where you want the pods from different RCs to land. You just don't want "zones". > This stuff is scattered throughout the docs: > > > https://docs.openshift.org/latest/admin_guide/manage_nodes.html#updating-labels-on-nodes > > https://docs.openshift.org/latest/dev_guide/deployments.html#assigning-pods-to-specific-nodes > > I hope this helps. > > >> >> >> Content of /etc/ansible/hosts of my Ansible hosting VM: >> >> [masters] >> >> sv5305.selfdeploy.loc >> >> # host group for nodes, includes region info >> >> [nodes] >> >> sv5305.selfdeploy.loc openshift_node_labels="{'region': 'infra', 'zone': >> 'default'}" openshift_schedulable=false >> >> sv5306.selfdeploy.loc openshift_node_labels="{'region': 'primary', >> 'zone': 'east'}" >> >> sv5307.selfdeploy.loc openshift_node_labels="{'region': 'primary', >> 'zone': 'west'}" >> >> >> >> Thank you in advance. >> >> >> >> Regards, >> >> >> >> Olga >> >> >> >> _______________________________________________ >> dev mailing list >> dev@lists.openshift.redhat.com >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> > > _______________________________________________ > dev mailing list > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > >
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
