Home > Blogs > VMware vFabric Blog

Three Reasons why you need vFabric Administration Server

In the 5.1 release of the vFabric Suite, we’ve added a new tool – vFabric Administration Server (VAS). VAS makes it significantly easier to administer some of the components of the vFabric Suite across small deployments with a handful of machines or something much larger. The first release of the Administration Server provides support for administering GemFire, RabbitMQ, and tc Server via a REST API. Some examples of VAS’s capabilities include installing GemFire, RabbitMQ, or tc Server, starting and stopping them, managing their configuration files, and deploying web applications to tc Server.

While there are more capabilities, here are three reasons why you need vFabric Administration Server:

  1. Improved Deployment Consistency and Time Savings
  2. Quick and Easy Scale Up and Down
  3. Simplified and Centralized Administration

Improved Deployment Consistency and Time Savings

VAS-group-membersA common problem encountered by our customers is ensuring that their deployments are consistent when spread across multiple machines. It’s all too easy for a deployment that started out with identically configured machines to slowly diverge as changes are made inconsistently across the machines. vFabric Administration Server addresses this by building upon the concept of a single system image, i.e. a collection of systems that are used as a single system. In VAS, a single system image is known as a group, with each system in the group being called a node.

Once a group has been created from one or more nodes, every operation that’s performed on the group is automatically applied to every node in the group. For example, if you want to deploy a web application across four tc Server instances, each hosted on a different node, you’d simply group the four nodes together and then work with the group to install tc Server, create the instance, and deploy the application. VAS will ensure that each step is performed on each node in the group, and, to ensure that it’s scalable, the operations are performed across all of the nodes in parallel. The use of a group prevents you from inadvertently making a change on a single node Ensuring consistency can also save you money as you no longer waste time troubleshooting the problems caused by inconsistencies in your deployments.

There are some notable exceptions where consistency does not apply. For example, the log files on each individual node will differ, and presenting a single unified view does not make sense. For such cases, vFabric Administration Server gives you limited node-specific access so that you can access logs files, disk stores from GemFire cache servers, etc. without jeopardizing the group’s consistency.

Quickly and Easily Scale Up and Down

A major benefit of working with groups is the ease of scaling your deployments up and down. To scale up GemFire, RabbitMQ, or tc Server, all you need to do is add additional nodes to a group. Conversely, all you need to do is remove some nodes from a group when scaling down. When scaling down, vFabric Administration Server will automatically clean up the nodes that have been removed from the group. When scaling up, VAS will automatically bring the newly added nodes to the same state as the group’s existing members.

Simplified and Centralized Administration

For common functions like installing, starting, and stopping, vFabric Administration Server uses a “common” user interface and API function across tc Server, RabbitMQ, or GemFire. VAS also needed to provide access to component-specific functionality where appropriate. For example, plugins are unique to RabbitMQ and templates are unique to tc Server. For unique areas, component-specific APIs are provided. In short, where the concepts are common, the APIs are common. And, where the concepts are component-specific, the APIs are component-specific. This approach simplifies administration by making all VAS-supported components work with a consistent, coherent API. REST-API-screencap

We also wanted the API to be usable from many different programming languages to reflect the wide range of languages typically used by today’s administrators. Using REST for the API satisfies this goal as it means that any language that can work with HTTP and JSON can use it.

Another advantage of the API is that it provides a well-defined base that we can build upon, for example by providing language-specific bindings. The bindings allow you to work with VAS without having to deal with the details of the REST API – the formatting of requests and parsing of responses is done for you. Over the coming weeks we’ll be providing language-specific bindings for both Ruby and Python which will allow you to administer GemFire, RabbitMQ, and tc Server, with a consistent API in a single Ruby or Python script.

Learning more

You can learn more by reading the product documentation and the REST API documentation. You may also be interested in vFabric on GitHub. Eventually, it will house the language-specific bindings and a number of samples showing how to use them.

Awilkinson About the Author: Andy Wilkinson is the lead developer of vFabric Administration Server (VAS). He joined VMware in 2009 as part of the SpringSource acquisition and has over ten years’ experience in middleware development. Prior to working on VAS he led the development of vFabric tc Server. During his time at SpringSource he was a member of the dm Server team and led the development of its second release.
  Speak with an Expert:
> vfabric@vmware.com
> 855 TRY VFABRIC (879 8322)
> +1 650 427 3100

21 thoughts on “Three Reasons why you need vFabric Administration Server

  1. اخبار اجتماعی

    For common functions like installing, starting, and stopping, vFabric Administration Server uses a “common” user interface and API function across tc Server, RabbitMQ, or GemFire. VAS also needed to provide access to component-specific functionality where appropriate. For example


Leave a Reply

Your email address will not be published. Required fields are marked *