Re: AW: Router Sharding

2016-09-27 Thread Phil Cameron 
The discussion on routing has been improved in the latest 3.3 docs. 
Please take a look and see if it is helpful.


With sharding each route gets one or more labels and each router (shard) 
has a selector that selects a set of routes by label. So it is up to the 
user/admin to assign labels to the routes and then to select a set of 
routes on each router (shard). By default a router selects all routes, 
so when sharding is used all routers (including the default router) will 
need to have a selector.


ipf (VIP using VRRP) deployment selects a set of nodes on which to 
present the supplied set of ip addresses. At any point in time one of 
the nodes is the master and it receives the packets to the IP address. 
So a single IP address can be set in DNS with knowledge that it will be 
serviced by one of the nodes. This implies that the application has 
replicas running on all of the nodes in the set.


phil

On 09/26/2016 04:53 PM, Aleksandar Lazic wrote:


Hi.

I agree with you, and I have tried to contribute to the doc but that’s 
wasn’t an easy task so I stopped.


Maybe I was also to naïve so blame me that I have stopped contribution.

@1: Currently that’s not possible you will need to add for every route 
the label for the dedicate router.


‘oc create route …’

have no options to set labels you will need to use

oc expose service ... --labels='router=one' --hostname='...'

or you can use the labels in the webconsole.

Oh and by the way the default router MUST also have ROUTE_LABELS if 
you don’t want to expose all routes to the default router.


@2: you will need the new template from OCP 3.3 there are additional 
env variables necessary to be able to use more the none router on the 
same node.


https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L147

https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L184

and you need to add on the router nodes in the iptables chain 
‘OS_FIREWALL_ALLOW’ the additional ports.


@3: This would be a little bit tricky on the same node due to the fact 
that the


https://github.com/openshift/origin/blob/master/images/ipfailover/keepalived/lib/failover-functions.sh#L11-L12

only handle one config file. Maybe there is a way with *VIPS but I 
have never tried this.


Hth

Aleks

*Von:*users-boun...@lists.openshift.redhat.com 
[mailto:users-boun...@lists.openshift.redhat.com] *Im Auftrag von 
*Srinivas Naga Kotaru (skotaru)

*Gesendet:* Montag, 26. September 2016 21:31
*An:* Andrew Lau ; users@lists.openshift.redhat.com
*Betreff:* Re: Router Sharding

Current sharding documentation is very high level, doesn’t cover step 
by step actual real world use cases.


Anyway, I was succeeded to create 2 shards. Lot of questions on this 
topic on how to proceed next …


1.How to tell a project that all apps created on this project should 
use router #1 or router #2?


2.Now we have 3 routers (default created as part of installation + 
additional 2 routers created). How the ports work? 80, 443 & 1936 
assigned to default router. I changed ports to 81/444/1937 and 
82/445/1938 to respectively shad #1 #2. These ports open automatically 
or explicit action required?


3.Ipfailover (floating VIP) bound to default router. Do we need to 
create additional IP failover pods with different IP’s and match to 
shad #1 and #2? Or can we share same IP failover pods with single 
floating VIP to newly created shad’s as well?


--

*Srinivas Kotaru*

*From: *Andrew Lau >
*Date: *Friday, September 23, 2016 at 7:41 PM
*To: *Srinivas Naga Kotaru >, "users@lists.openshift.redhat.com 
" 
>

*Subject: *Re: Router Sharding

There are docs here:

- 
https://docs.openshift.org/latest/architecture/core_concepts/routes.html#router-sharding


- 
https://docs.openshift.org/latest/install_config/router/default_haproxy_router.html#creating-router-shards


On Sat, 24 Sep 2016 at 06:13 Srinivas Naga Kotaru (skotaru) 
> wrote:


Just saw 3.3 features blog

https://blog.openshift.com/whats-new-openshift-3-3-cluster-management/

We’re rethinking of our cluster design and want to consolidate 1
cluster per data center. Initially we were planning off 2 cluster
per data center to server internal and external traffic dedicated
to its own cluster.

Consolidating to a single cluster per DC will offer multiple
advantages to us.  We currently running latest 3.2.1 release

Router Sharding is available in 3.2.x branch or need to wait for
3.3? I was thinking this feature has been available from 3.x
onwards as per documentation available. Not sure what is mean for
upcoming 3.3.

We really want to take advantage

Re: AW: Router Sharding

2016-09-26 Thread Srinivas Naga Kotaru (skotaru) 
It seems writing documentation is difficult then coding. I always felt the 
other way ☺

I been scratching my head last 2 days to test basic use case of multiple 
routers/shards but no luck yet.

With all due to respect, OpenShift documentation has to be improved a lot for 
real consumption. Current documentation is very high level. We have to spend 
lot of time to understand, how a feature really works in multiple contexts. 
It’s all at all written keeping customer or platform teams in the mind. Just to 
prove a feature, taking a weeks and weeks to understand, POC and prove it. Lot 
of time waste …

Shards feature is similar to multiple routers deployment (every router has its 
own IP failover pods, floating IP, same ports to avoid port conflict)? Since 
every router has its own floating IP address, no more ports conflict (80/443) 
or no special IP tables rules required?

Or sharing is different than multiple routers deployment??

--
Srinivas Kotaru

From: Aleksandar Lazic <aleksandar.la...@cloudwerkstatt.com>
Date: Monday, September 26, 2016 at 1:53 PM
To: Srinivas Naga Kotaru <skot...@cisco.com>, Andrew Lau 
<and...@andrewklau.com>, "users@lists.openshift.redhat.com" 
<users@lists.openshift.redhat.com>
Subject: AW: Router Sharding

Hi.

I agree with you, and I have tried to contribute to the doc but that’s wasn’t 
an easy task so I stopped.
Maybe I was also to naïve so blame me that I have stopped contribution.

@1: Currently that’s not possible you will need to add for every route the 
label for the dedicate router.

‘oc create route …’

have no options to set labels you will need to use

oc expose service ... --labels='router=one' --hostname='...'

or you can use the labels in the webconsole.

Oh and by the way the default router MUST also have ROUTE_LABELS if you don’t 
want to expose all routes to the default router.

@2: you will need the new template from OCP 3.3 there are additional env 
variables necessary to be able to use more the none router on the same node.

https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L147
https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L184

and you need to add on the router nodes in the iptables chain 
‘OS_FIREWALL_ALLOW’ the additional ports.

@3: This would be a little bit tricky on the same node due to the fact that the

https://github.com/openshift/origin/blob/master/images/ipfailover/keepalived/lib/failover-functions.sh#L11-L12

only handle one config file. Maybe there is a way with *VIPS but I have never 
tried this.

Hth

Aleks

Von: users-boun...@lists.openshift.redhat.com 
[mailto:users-boun...@lists.openshift.redhat.com] Im Auftrag von Srinivas Naga 
Kotaru (skotaru)
Gesendet: Montag, 26. September 2016 21:31
An: Andrew Lau <and...@andrewklau.com>; users@lists.openshift.redhat.com
Betreff: Re: Router Sharding


Current sharding documentation is very high level, doesn’t cover step by step 
actual real world use cases.

Anyway, I was succeeded to create 2 shards. Lot of questions on this topic on 
how to proceed next …


1.  How to tell a project that all apps created on this project should use 
router #1 or router #2?

2.  Now we have 3 routers (default created as part of installation + 
additional 2 routers created). How the ports work? 80, 443 & 1936 assigned to 
default router. I changed ports to 81/444/1937 and 82/445/1938 to respectively 
shad #1 #2. These ports open automatically or explicit action required?

3.  Ipfailover (floating VIP) bound to default router. Do we need to create 
additional IP failover pods with different IP’s and match to shad #1 and #2? Or 
can we share same IP failover pods with single floating VIP to newly created 
shad’s as well?

--
Srinivas Kotaru

From: Andrew Lau <and...@andrewklau.com<mailto:and...@andrewklau.com>>
Date: Friday, September 23, 2016 at 7:41 PM
To: Srinivas Naga Kotaru <skot...@cisco.com<mailto:skot...@cisco.com>>, 
"users@lists.openshift.redhat.com<mailto:users@lists.openshift.redhat.com>" 
<users@lists.openshift.redhat.com<mailto:users@lists.openshift.redhat.com>>
Subject: Re: Router Sharding

There are docs here:
- 
https://docs.openshift.org/latest/architecture/core_concepts/routes.html#router-sharding
- 
https://docs.openshift.org/latest/install_config/router/default_haproxy_router.html#creating-router-shards


On Sat, 24 Sep 2016 at 06:13 Srinivas Naga Kotaru (skotaru) 
<skot...@cisco.com<mailto:skot...@cisco.com>> wrote:
Just saw 3.3 features blog

https://blog.openshift.com/whats-new-openshift-3-3-cluster-management/

We’re rethinking of our cluster design and want to consolidate 1 cluster per 
data center. Initially we were planning off 2 cluster per data center to server 
internal and external traffic dedicated to its own cluster.

Consolidating to a single cluster per DC wil

AW: Router Sharding

2016-09-26 Thread Aleksandar Lazic 
Hi.

I agree with you, and I have tried to contribute to the doc but that’s wasn’t 
an easy task so I stopped.
Maybe I was also to naïve so blame me that I have stopped contribution.

@1: Currently that’s not possible you will need to add for every route the 
label for the dedicate router.

‘oc create route …’

have no options to set labels you will need to use

oc expose service ... --labels='router=one' --hostname='...'

or you can use the labels in the webconsole.

Oh and by the way the default router MUST also have ROUTE_LABELS if you don’t 
want to expose all routes to the default router.

@2: you will need the new template from OCP 3.3 there are additional env 
variables necessary to be able to use more the none router on the same node.

https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L147
https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L184

and you need to add on the router nodes in the iptables chain 
‘OS_FIREWALL_ALLOW’ the additional ports.

@3: This would be a little bit tricky on the same node due to the fact that the

https://github.com/openshift/origin/blob/master/images/ipfailover/keepalived/lib/failover-functions.sh#L11-L12

only handle one config file. Maybe there is a way with *VIPS but I have never 
tried this.

Hth

Aleks

Von: users-boun...@lists.openshift.redhat.com 
[mailto:users-boun...@lists.openshift.redhat.com] Im Auftrag von Srinivas Naga 
Kotaru (skotaru)
Gesendet: Montag, 26. September 2016 21:31
An: Andrew Lau ; users@lists.openshift.redhat.com
Betreff: Re: Router Sharding


Current sharding documentation is very high level, doesn’t cover step by step 
actual real world use cases.

Anyway, I was succeeded to create 2 shards. Lot of questions on this topic on 
how to proceed next …


1.  How to tell a project that all apps created on this project should use 
router #1 or router #2?

2.  Now we have 3 routers (default created as part of installation + 
additional 2 routers created). How the ports work? 80, 443 & 1936 assigned to 
default router. I changed ports to 81/444/1937 and 82/445/1938 to respectively 
shad #1 #2. These ports open automatically or explicit action required?

3.  Ipfailover (floating VIP) bound to default router. Do we need to create 
additional IP failover pods with different IP’s and match to shad #1 and #2? Or 
can we share same IP failover pods with single floating VIP to newly created 
shad’s as well?

--
Srinivas Kotaru

From: Andrew Lau >
Date: Friday, September 23, 2016 at 7:41 PM
To: Srinivas Naga Kotaru >, 
"users@lists.openshift.redhat.com" 
>
Subject: Re: Router Sharding

There are docs here:
- 
https://docs.openshift.org/latest/architecture/core_concepts/routes.html#router-sharding
- 
https://docs.openshift.org/latest/install_config/router/default_haproxy_router.html#creating-router-shards


On Sat, 24 Sep 2016 at 06:13 Srinivas Naga Kotaru (skotaru) 
> wrote:
Just saw 3.3 features blog

https://blog.openshift.com/whats-new-openshift-3-3-cluster-management/

We’re rethinking of our cluster design and want to consolidate 1 cluster per 
data center. Initially we were planning off 2 cluster per data center to server 
internal and external traffic dedicated to its own cluster.

Consolidating to a single cluster per DC will offer multiple advantages to us.  
We currently running latest 3.2.1 release

Router Sharding is available in 3.2.x branch or need to wait for 3.3? I was 
thinking this feature has been available from 3.x onwards as per documentation 
available. Not sure what is mean for upcoming 3.3.

We really want to take advantage of this feature and test ASAP. Current 
documentation is not clear or explains only high level.

Can you help me or point to right documentation which explains step by steps to 
test this feature?

Can we control routes at project level so that clients wont modifies to move 
their routes from prod to non-prod or internal to external routers?

--
Srinivas Kotaru
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users