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

Horizontal Scaling: Service Routing #72

Open
chris-allan opened this issue Jan 26, 2017 · 0 comments
Open

Horizontal Scaling: Service Routing #72

chris-allan opened this issue Jan 26, 2017 · 0 comments

Comments

@chris-allan
Copy link
Member

History, state of play, and rationale

Horizontally scaled versions of OMERO are applicable to many use cases. Building upon a pure read-only instance of OMERO (#71) a transparent, horizontally scaled ability to utilize multiple OMERO instances, classified as either read-only or read-write, at a time is strongly desired. The only client exposure to this ability is a "pure read-only" parameter to disable access to read-write methods when creating a read-only/read-write stateful service. This decision would persist for the entire lifecycle of a service created in such a manner.

Overview

The second major step in "Horizontal Scaling" is to allow a single connection to an OMERO instance to transparently route service creation or retrieval requests to a readable or writable OMERO instance. This instance will then host the service based on the needs of that service request for the duration of its lifecycle. All requests for stateless services can be executed by any appropriate (based on the read-only or read-write requirement of the request) OMERO instance endpoint. Note that a shared filesystem will need to be in place between OMERO instances for this to be possible for certain service types which access the OMERO binary repository.

Read-only or read-write services will need to be classified ahead of time, bound for the length of the session and stored in a persistent, cluster-wide manner. If a node is removed from the cluster its associated stateful services will be destroyed with it and the client developer will be expected to handle such a failure condition.

For stateful services that have methods which have both read-only and read-write containment, a default of a writeable endpoint will be necessary. An optional parameter to disable access to read-write methods when creating a service of this type will be provided.

The result of this work is a transparent, horizontally scaled ability to utilize multiple OMERO instances, classified as either read-only or read-write, at a time. The only client exposure to this ability is a "pure read-only" parameter to disable access to read-write methods when creating a read-only/read-write stateful service. This decision would persist for the entire lifecycle of a service created in such a manner.

This could facilitate an automatic means of load balancing (for read-only), such as round-robining of requests.

Current work

OMERO 5.2.x

OMERO 5.3.x

TBD

Related reading

History

Thu Jan 26 12:46:30 GMT 2017: Initial version

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

1 participant