Over 37,000 VMs have been started in Hands on Labs. Hands on Labs run in Hall 6 through Thursday. vFabric labs include Application Director, Data Director, CloudFoundry, SQLFire and scaling with vFabric.
As noted in the Field Report from Day 2, we greatly appreciate the opportunity to listen and learn from our VMworld Europe customers, prospects, and partners! VMworld this year has not dissapointed. We’ve met with hundreds of partners, thousands of customers and spun up tens of thousands of virtual machines in our hands on labs. Over 37,000 in fact at the start of Wednesday, with two more full days to go! An impressive event all around.
Not surprisingly after the keynote yesterday, customer discussions have continued on Application Director, with many stating explicitly that they are going to use this as the cornerstone opportunity to build out a self-service infrastructure, just like VMware’s own IT did.
Beyond that, a few other key themes have emerged:
Significant vFabric Interest from VMware Partners
Monday was a partner day, and there is a lot of interest in vFabric from partners. They are looking to VMware to learn and improve how they are building apps for their customers in cloud environments. For one of our presentations on Monday, we had a packed house with over 100 people in the audience. Continue reading →
We’ve talked to dozens of people, and the theme we keep hearing is simplicity, simplicity, simplicity.
Many amazingly bright application architects have stopped by to understand and learn more about the vFabric application architecture, and these folks hail from a number of industries – giant telecom manufacturers, government ministries of defense, and multi-industry service companies to name a few.
These conversations with architects have tended to fall into one of the falling categories: Continue reading →
vFabric RabbitMQ, based on the open source RabbitMQ project, has significantly updated the underlying RabbitMQ version to 2.8.1 in the latest VMware vFabric Suite 5.1 update.
The new vFabric RabbitMQ release represents a significant upgrade from the open source RabbitMQ 2.4.1 that vFabric 5.0 was based on, and brings the commercially supported vFabric RabbitMQ to parity with recent open source RabbitMQ releases by rolling up all of the interim code changes. Furthermore, users now have the option of choosing to use the commercially bundled vFabric RabbitMQ from VMware or using the open source RabbitMQ distribution with a single license. Either way a user chooses, they can receive the same reliable support from VMware.
New internal message flow control to limit memory use and make performance more predictable if the server is overloaded
Recovery has been simplified, improving startup times when many exchanges or bindings exist
Better performance under high load and memory pressure
Improved inbound network performance
Improved routing performance
Significant performance improvements to connection creation, durable queues, message storage, and large numbers of consumers
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:
Improved Deployment Consistency and Time Savings
Quick and Easy Scale Up and Down
Simplified and Centralized Administration
Improved Deployment Consistency and Time Savings
A 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.
Elastic Memory for Java (EM4J) 1.1 is a memory management toolkit for Java in vSphere, focused on enabling customers to confidently achieve greater memory efficiency for their Java workloads.
EM4J is a relatively new technology developed here at VMware which was created to solve the problem of memory reclamation in VMs predominantly running Java. This week, as part of the overall vFabric Suite 5.1 release, we introduced EM4J 1.1 which builds on that foundation with new monitoring capabilities in vCenter designed specifically to support Java workloads, as shown in this screenshot. First, however, if you are not familiar with EM4J, it may be helpful for a more detailed background on EM4J itself. If you are already familiar with it, you can skip to the section below on EM4J 1.1.
In a nutshell, relational databases weren’t built for the cloud. With vFabric Postgres, VMware customers can get a proven, enterprise database integrated with VMware virtualization and ready for cloud computing.
As announced earlier this week, vFabric Postgres (vPostgres) is now available within vFabric Suite 5.1 Advanced. With vPostgres, the well-respected, open-source database gains built in best practices, optimized configuration, and cloud-ready features. While vFabric Postgres is synced up to PostgreSQL 9.1.3 minor release and includes all the new features of this version of the database (see PostgreSQL wiki for more), vFabric adds many features and considerable improvements in three categories:
1. Development and deployment become simpler, smarter, and cloud ready 2. Performance improvements with elastic memory and more 3. Monitoring and administration get an upgrade 4. Lower TCO and increased staff efficiency
Development and Deployment with vFabric Postgres
First, vPostgres is available in two form factors:
vPostgres Virtual Appliance
vPostgres RPMs for 64-bit Linux Servers (RHEL 6, Suse 11 sp1+)
Today we’re very happy to announce that our beta of vFabric SQLFire has been released!
There’s tremendous change underway today in data management. These days people are looking for databases that are faster, more scalable, more reliable, and can effortlessly serve users around the globe. We believe SQLFire does a great job addressing these concerns and more.
Since we’re all pretty busy and evaluating a product can be hard, I’m going to kick things with this little video tour through our quick start guide, covering install and running a few basic commands. Some of the important points it covers are:
The video shows how easy it is to add nodes to the database, or “distributed system” in our jargon. So it’s very easy to horizontally scale SQLFire. (Removing nodes is just as easy though the video doesn’t cover that.)
If you’ve scaled a system out you have to plan very explicitly for failure. If a member fails about once a year, and you’ve got 12 of them, you can expect one failure per month. 24 members, you can expect 2 per month. You get the idea. The video shows that if a distributed system member fails for some reason, SQLFire clients will automatically connect to some other member in the system.
In our formal marketing-speak we describe SQLFire as a memory-oriented, shared-nothing distributed data management system that uses SQL as its interface.
Memory-oriented: SQLFire is memory-oriented in the sense that regular data accesses are all done purely in memory. SQLFire can also write data to disk, which you might do to protect yourself from a crash, but data is not written to disk in a way that is used for random data retrievals. Traditional databases work very hard to optimize around disk access, and use a lot of tricks to try to minimize disk seeks, structure data sequentially, etc. With SQLFire, queries and data retrieval are done purely in memory for maximum speed. Anybody who watches the prices and configuration of servers knows that memory volumes are getting huge, a server with 1 terabyte of RAM costs well under $50,000 these days, in a few years we’ll look back and laugh at servers that “only” have 1TB of RAM. Quite a lot of databases will fit very happily inside 1TB and SQLFire is taking advantage of this industry shift.
Shared-nothing and distributed: Another big shift that’s been underway for a while is the shift away from big, monolithic systems toward scale-out systems built from commodity hardware. The big web giants really pioneered this shift but a lot of people still aren’t benefiting from it. SQLFire embraces scale-out by making it trivial to add and remove capacity at any time.
There’s a lot more in SQLFire I didn’t cover here, so be sure to download SQLFire and try it yourself. Visit the SQLFire Community to get everything you need, and be sure to check in on the Discussions tab and let us know what you think!