Thursday, August 21, 2014
From FutureGrid to NSFCloud
Yesterday, the National Science Foundation announced the NSFCloud awards. FutureGrid partners, University of Chicago and TACC won one of them to build an experimental testbed called Chameleon. We are excited to be able to continue serving the FutureGrid community through this new project!
The FutureGrid resources at University of Chicago and TACC, Hotel and Alamo, will continue to be operated during the first year of the Chameleon project. We will provide documentation and tools as necessary to streamline user transition from FutureGrid to Chameleon so that FutureGrid users can keep their data and access these resources easily. We will also make every effort to ensure that the resource availability under the new project overlaps with FutureGrid.
Initially the resources will be operated in roughly the same way as they are now operated in FutureGrid with the exception that the "HPC partitions" will not be supported. We will continue the process of transitioning users to the OpenStack clouds. In Spring of 2015, we expect to introduce additional capabilities allowing users to work with bare metal reconfiguration while continuing to operate OpenStack clouds for research and educational projects as before. In the Fall of 2015, the existing Hotel and Alamo resources will be supplanted by new hardware consisting of over 650 multi-core nodes equipped with OpenFlow switches and a total of 5 PB of storage. The operational model of the resources will remain the same in the essentials but will be progressively refined to support increasingly more experiments.
To find out more, please visit our website, www.chameleoncloud.org. We will also post regular updates as the project gets underway.
Monday, August 11, 2014
Important Changes!
After almost five years of operation, the FutureGrid project will come to an end on September 30th. There will be several options for current users who wish to continue their work after that date.
The Indiana University machines Xray, India, Bravo, Delta, Echo will continue running roughly as is for both education and research (with greater use of Cloudmesh tool and a different access portal), and additional possibilities via other projects will be described in a detailed announcement in the next few weeks. In particular, we expect that testbeds funded by the NSFCloud solicitation (http://www.nsf.gov/pubs/2013/nsf13602/nsf13602.htm) will be available to welcome FutureGrid users as FutureGrid is ending. These testbeds will focus on supporting research and development in cloud computing. Further High performance computing and data intensive computing users can request time on other XSEDE resources.
See https://www.xsede.org/resources/overview for a description of XSEDE resources and https://portal.xsede.org/allocations-overview for information on how to request access.
Please submit a ticket or send email to help@futuregrid.org if you need help before details on future options are available.
Please submit a ticket or send email to help@futuregrid.org if you need help before details on future options are available.
Thank you, Geoffrey
Tuesday, July 15, 2014
New Phantomize feature: automatic installation of tcollector sensor agent
We are happy to announce "phantomize", a Phantom feature that will automatically install and run the tcollector sensor agent on the first boot of your virtual machines thereby automatically instrumenting your VMs to provide sensor measurements.
Phantom offers autoscaling based on sensor measurements from a variety of sources, including user's virtual machines. To collect these measurements, Phantom relies on the tcollector sensor agent being running on each of those virtual machines. Until now, users had to manually install tcollector in their virtual machines or use an image provided by us with tcollector already installed. The former requires extra effort and the latter restricts the user to the types of images provided by us.
The phantomize feature addresses this problem. To use it, all the user needs to do is pick the "phantomize" contextualization type in their launch configuration settings. The only requirement is that the user's virtual machine image is capable of downloading and executing the user-data script on boot.
Phantomize has been tested successfully with Debian, Fedora, and Ubuntu virtual machines on FutureGrid clouds running Nimbus and OpenStack.
Phantom offers autoscaling based on sensor measurements from a variety of sources, including user's virtual machines. To collect these measurements, Phantom relies on the tcollector sensor agent being running on each of those virtual machines. Until now, users had to manually install tcollector in their virtual machines or use an image provided by us with tcollector already installed. The former requires extra effort and the latter restricts the user to the types of images provided by us.
The phantomize feature addresses this problem. To use it, all the user needs to do is pick the "phantomize" contextualization type in their launch configuration settings. The only requirement is that the user's virtual machine image is capable of downloading and executing the user-data script on boot.
Phantomize has been tested successfully with Debian, Fedora, and Ubuntu virtual machines on FutureGrid clouds running Nimbus and OpenStack.
Friday, June 6, 2014
OpenStack Hotel now supports the native OpenStack APIs
We have changed the configuration of the OpenStack Hotel cloud so that users can now access the native OpenStack APIs over secure HTTP connections.
You can download your OpenStack credentials file from the web interface via the "Access & Security" link in the left of any page and then click on the "API Access" link on the top.
You can download your OpenStack credentials file from the web interface via the "Access & Security" link in the left of any page and then click on the "API Access" link on the top.
Wednesday, June 4, 2014
FutureGrid multi-cloud VM image generator now available
We are happy to announce the alpha release of our newest tool for FutureGrid users: a multi-cloud VM image generator.
FutureGrid offers access to multiple clouds based on several different technologies (Nimbus, OpenStack, and Eucalyptus) using different hypervisors (Xen or KVM). Users can also supplement the use of FutureGrid resources by bursting out to commercial clouds such as Amazon EC2. While this allows users to use multiple clouds, such access is often hard to leverage as VM images are generally not portable across different formats and cloud providers.
This presents users with a few problems. First, moving from one cloud to another means creating a new image; this is time-consuming and error-prone. Second, users typically want the VM images to represent a consistent environment independently of what type of cloud the image is deployed on; this is hard to achieve using a manual configuration process as even small differences in configuration can have significant consequences. Third, even if the user does produce a set of images that are initially consistent, as images subsequently evolve it is hard to keep track of which changes were applied to which image. In short, the problem is the lack of traceability and repeatability of VM image customizations.
Our image generator aims to solve these problems by providing an interface to specify a customization script that can be used to generate consistent images for many clouds. The service starts out with a set of consistent images uploaded to several clouds, applies them to those images, and creates a new VM image on each cloud.
We invite you to try our image generator by following our online tutorial, and please report any issue of request to nimbus-phantom@lists.mcs.anl.gov.
FutureGrid offers access to multiple clouds based on several different technologies (Nimbus, OpenStack, and Eucalyptus) using different hypervisors (Xen or KVM). Users can also supplement the use of FutureGrid resources by bursting out to commercial clouds such as Amazon EC2. While this allows users to use multiple clouds, such access is often hard to leverage as VM images are generally not portable across different formats and cloud providers.
This presents users with a few problems. First, moving from one cloud to another means creating a new image; this is time-consuming and error-prone. Second, users typically want the VM images to represent a consistent environment independently of what type of cloud the image is deployed on; this is hard to achieve using a manual configuration process as even small differences in configuration can have significant consequences. Third, even if the user does produce a set of images that are initially consistent, as images subsequently evolve it is hard to keep track of which changes were applied to which image. In short, the problem is the lack of traceability and repeatability of VM image customizations.
Our image generator aims to solve these problems by providing an interface to specify a customization script that can be used to generate consistent images for many clouds. The service starts out with a set of consistent images uploaded to several clouds, applies them to those images, and creates a new VM image on each cloud.
We invite you to try our image generator by following our online tutorial, and please report any issue of request to nimbus-phantom@lists.mcs.anl.gov.
Subscribe to:
Posts (Atom)