What you should know about Orca’s agent
Smaller, faster, street-smart
We get a lot of questions about our agent. In fact, we are often asked why Orca even uses an agent. This page provides all the information you need to know about our agent – why it’s needed, why it’s better, and why it’s so powerful.
First impressions can be lasting impressions
We have found that the arguments against agents are usually related to really bad experiences with very poorly written agents. In many cases, companies develop agents without really considering the right tool for the job. That means you wind up with a Java-based agent that brings along with it a massive runtime that has a very large footprint, creates a drain on system resources and is slow to perform. In other cases companies develop agents that have a bunch of system requirements and pre-requisites, making agent installation and upgrade much more difficult than it needs to be.
Small footprint of 5-8 MB
No other runtimes or pre-requisite configuration required
Agent routing handles large environments
Navigates network firewalls
Operates on a single port
Run as any user
Contained to a single directory
Simple to install and easy to maintain
But agents are necessary
On the other hand, having an agent allows for a degree of capability and control that you just can’t get with an agentless system. An agent purposely built to support the software application can interact with systems in ways that typically are not possible with agentless setups. Agents have direct control over the tasks they perform, can manage I/O effectively, and deal with hangs and error conditions far better.
Agentless setups aren’t really agentless
When you see “agentless”, you’re almost always talking about using SSH. But that’s really an agent. It’s an agent that accepts incoming user connections, manages them, and deals with the processes, I/O, and connection issues directly.
The problem is, SSH was designed to be an agent to manage interactive connections from users, not to remote execute tasks. It has no intelligence, so you can run a command and capture the output – that’s it. When using public key authentication (which is typically encouraged over password mode), you have additional configurations to manage on your endpoints, which causes the same management issues (if not more) as installing an agent.
Enter: Orca’s agent
Orca’s agent is designed to be highly efficient, scalable, and perform the specific tasks needed to effectively control remote task execution. Orca’s agent is a standalone, universal binary that runs on a single port – it requires no other runtimes or pre-requisite configuration. It’s also small, 5-8 MB depending on the platform. It will start and run as a system service with no configuration requirements. It also contains itself to a single directory, and removing that directory removes all traces of the agent, so you can be confident that the agent is completely self-contained and not affecting anything else running on your system. Also, the agent lives in passive mode 99% of the time, waiting for requests to kick off, so you don’t need to be worried about resource consumption on your servers.
Orca’s agent can change users
The agent system service can be run an administrative or super user (root), or it can be installed and run as any other local or domain user. If you install the agent to run as an administrative or super user, Orca can change to different users depending on the connection that’s made. For example, you may have operating system configurations that need to be managed, middleware to manage, and applications to deploy all on one server. Orca can perform operating system tasks as one user and make middleware or database configuration changes or deployments as a different user. This is especially helpful when you start managing databases, middleware, and the supporting OS from the same product (Orca of course!).
Orca understands your firewalls… and your large environment
More importantly, our agent paradigm understands routing. That means you can have a single connection to a data center through one IP and still effectively manage any number of servers behind that ‘firewall’ server. Orca sends a single compact request to that gateway agent, and that agent can then replicate and route that request to any number of servers, even if that means going through yet another gateway again. This is pretty important from a scaling perspective. A big issue for management systems that talk to a lot of servers is that they require direct connection to the initiating console.
For instance, say you need to send a configuration change to 500 servers. For other systems, all 500 agents must be able to talk to the console. That would create 500 simultaneous network connections, killing the console server and flooding the network.
Some products offer ‘throttle and tuning’ controls to achieve performance (really just helping hide the negative performance). They do this because their design is flawed. With Orca, you can specify a few ‘gateway’ servers (they don’t have to be firewall situations) and Orca will ‘fan out’ the request. This means the console sends out 5 or 6 requests, and those 5 or 6 fan out to 10 or 20, and those fan out to another 10, and so on.
But your Orca console does just a handful of connections and then goes about its business.
Inbound, the gateways provide a flow control for return requests. Think of a ping going out and fanning out at multiple points. Those pings follow that same route back so the gateway servers can collect and manage incoming responses, instead of 500 or a thousand servers all trying to push data to the console server all at once.
And from an agent management perspective, all of our agents are identical so there is no need to install a ‘proxy’ agent. You can dynamically design how your agents route within the Orca Console.
Contact us to learn more about the agent-based configuration management.