Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for deploying Aerospike Graph Service using Aerolab #251

Closed
ishaanb opened this issue Feb 26, 2024 · 1 comment
Closed

Add support for deploying Aerospike Graph Service using Aerolab #251

ishaanb opened this issue Feb 26, 2024 · 1 comment
Milestone

Comments

@ishaanb
Copy link

ishaanb commented Feb 26, 2024

Add option in Aerolab to deploy AGS (Aerospike Graph Service) using Aerolab. Following are the requirements

  1. add option to deploy AGS instance(s) locally or in the cloud (GCP and AWS)
  2. AGS to be deployed along with a load balancer (like nginx) in front so that user gets one endpoint
  3. Add option to specify number of AGS instances to be deployed
  4. Add option to deploy AGS instances when spinning up the database OR just add AGS instances with already deployed database cluster

Current product installation instructions
https://aerospike.com/docs/graph/getting-started/installation

@robertglonek robertglonek modified the milestones: 7.5.0, 7.6.0 Feb 29, 2024
@robertglonek
Copy link
Collaborator

This will be available in the next v7.5.0 prerelease for your testing, due to be built sometime tomorrow once my testing completes.

As per internal discussions, this will be provided:

aerolab client create graph -n NAME -c COUNT -C CLUSTER_NAME -m NAMESPACE

For example: aerolab client create graph -n bob -c 5 -C mycluster -m test.

This will work on GCP/AWS/Docker backends. The docker backend is a bit special as it cannot use the actual implementation of AeroLab's docker backend since it needs to launch a specific docker container. On AWS/GCP it installs and runs the docker container.

Other features will include:

  • -e | --extra allowing to provide extra properties configuration parameters, for example aerolab client create graph ... -e aerospike.client.timeout=2000 -e ...
  • --rm-mb allowing to limit RAM use. Default for docker backend is 4GB and for AWS/GCP it's 90% of total system memory

This satisfies points 1, 3 and 4. With option 4, you essentially deploy a node group of graph 'clients' to the aerospike server cluster. Installing graph on actual aerospike server nodes is not recommended as extra consideration to sizing and RAM utilization of both aerospike and graph would have to be taken into account, as well as possible delays caused by CPU load in either software.

I am going to reject point 2 - proxy. As TinkerPop/Gremlin uses WebSocket, a stateful WS load balancer is required, or an Application Load Balancer from AWS/GCP can be used when in cloud. An LB makes no sense in local docker backend. An LB is not recommended by the Gremlin team as it creates a single point of failure and possible network bottleneck on the load balancing proxy, as all traffic has to go through it.

If you need a load balancer, this can be easily achieved in a script. You would:

  1. deploy aerospike cluster
  2. deploy graph client instance group
  3. run aerolab client list -i to get a list of clients and their IPs in a nicely 'greppable' way
  4. create an nginxscript.sh that installs nginx and configures it to be a proxy with details from the above point 3
  5. use for example aerolab client create none -n proxy; aerolab files upload -n proxy nginxscript.sh /tmp/install.sh; aerolab attach client -n proxy -- bash /tmp/install.sh to create a client named 'proxy' and run the script on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants