Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:29:19 +0000.
Sender:Ian Harris.
Date:Tuesday, 27 October 2015 14:42:18 UTC.
Hi Martin,
I’m looking into a mechanism to scale our Tyk infrastructure and I’m hoping for a little guidance. Our current setup includes a host machine running docker containers for the host_manager, dashboard, gateway, mongo and redis.
To handle increased numbers of API requests inbound on the host manager I was planning on adding more (host_manager, dashboard, gateway) containers. Should each such set of containers be isolated from one another or is there a way to connect them?
Also, in such a set up how can I guarantee uniqueness in the database. For example, in the case that two dashboard instances (linked to the same set of dbs) are handling key creation requests via the Advanced managment API how can I guarantee there aren’t collisions in the generated key ids?
Thanks,
Ian.
Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 27 October 2015 15:09:45 UTC.
Hi Ian,
To scale things you will need to separate out the DB and Redis from the Tyk stack, you can scale the tyk_nginx, tyk_gateway and tyk_docker containers together on the same instance, horizontally but they will all need to point at a Redis box or redis cluster and mongo DB instance(s).
If you are running each of the three containers on the same instance (per instance), then you can keep the configuration files the same and only replace the connection settings for redis and mongo in tyk.conf, tyk-analytics.conf and host_manager.json. The Tyk stack is designed to scale, you just need to manage the data layer.
If you are scaling this out, I wouldn’t use the redis and Mongo containers, as you’ll probably want to configure some kind of failover for redis (usually HAProxy + Sentinel + Redis Master / Slave or if you are on AWS: Elasticache with muti-AZ standby), and a replica-set Mongo DB instance. If your Redis instance goes down (unless you are writing to disk - not recommended), then your keys will all go.
As for key uniqueness, key generation is done at the node level (the gateway nodes generate keys, not the dashboard or advanced API), and when it does it uses a UUIDv4 to ensure uniqueness, so there is an extremely low chance of collisions.
Hope that helps,
Cheers,
Martin
Imported Google Group message.
Sender:Ian Harris.
Date:Tuesday, 27 October 2015 15:09:45 UTC.
Hi Ian,
To scale things you will need to separate out the DB and Redis from the Tyk stack, you can scale the tyk_nginx, tyk_gateway and tyk_docker containers together on the same instance, horizontally but they will all need to point at a Redis box or redis cluster and mongo DB instance(s).
If you are running each of the three containers on the same instance (per instance), then you can keep the configuration files the same and only replace the connection settings for redis and mongo in tyk.conf, tyk-analytics.conf and host_manager.json. The Tyk stack is designed to scale, you just need to manage the data layer.
If you are scaling this out, I wouldn’t use the redis and Mongo containers, as you’ll probably want to configure some kind of failover for redis (usually HAProxy + Sentinel + Redis Master / Slave or if you are on AWS: Elasticache with muti-AZ standby), and a replica-set Mongo DB instance. If your Redis instance goes down (unless you are writing to disk - not recommended), then your keys will all go.
As for key uniqueness, key generation is done at the node level (the gateway nodes generate keys, not the dashboard or advanced API), and when it does it uses a UUIDv4 to ensure uniqueness, so there is an extremely low chance of collisions.
Hope that helps,
Cheers,
Martin
Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 30 October 2015 09:08:54 UTC.
Hi Martin,
That’s great. I’ve been looking at splitting out the DBs and think I have it all ready now.
Thanks for your help,
Ian.