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

Reply via email to