As with Cloud Computing, device independence and the use of Internet is an essential requirement for self Service IT Solutions. Self Service Platforms should be accessible via standard technologies such as HTML. Especially monitoring tools should be offered by the platform. Since self Service IT Platforms are basically within enterprise environments, it is necessary to have advanced security such as corporate firewalls applied.
The goal of self Service IT is to improve processes within the enterprise and to improve the performance of the IT department. Processes should be more transparent and easier to use for end-users within the enterprise. Therefore, it is necessary that a self Service platform show immediate effects. If the user needs to create a new marketing website, the instances should be launched within some minutes and if scaling is needed, it should also be possible within some minutes. The user should get access to new instances once the user needs or demands for them. There should be no form to fill out and send to the IT department just to have instances available after some days or weeks.
http://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.png00Mario Meir-Huberhttp://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.pngMario Meir-Huber2013-05-28 17:28:262013-05-28 17:28:26Self service IT Requirements: device independence and on demand
I recently updated my Skydrive to the newest version on Mac OS X. I am using 10.8.3 (Mountain Lion). However, I came across a sync issue with Skydrive. The program seemed to stop working, the Skydrive Icon was only gray. I then looked at the forums and it turned out that this is due to a verisign host header entry. To solve this issue, simply do the following:
1. Start the Terminal. You can get there by opening the Launchpad and type “Terminal”
Nano edit a host file on OS X 10.8 (Mountain Lion)
2. In the terminal, run nano (the editor for OS X). It needs to have additional rights (sudo). Start nano with the hosts header, with the following command:
$ sudo nano /private/etc/hosts
3. Scan the file for “ctrl.verisign.net” and comment that out by adding a # at the beginning of the file.
http://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.png00Mario Meir-Huberhttp://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.pngMario Meir-Huber2013-05-23 13:06:222013-05-23 13:06:22Microsoft Skydrive sync problems on Mac OS
This post is part of the Open Source Cloud Computing series. For an Overview, please click on the Tag.
The Cloud Controller – also known as CLC – is the highest level in Eucalyptus. There is one Cloud Controller per infrastructure. The Cloud Controller is in charge of the following tasks:
Connect to virtual instances via SSH
Provide a Front end for the Web Services that are EC2 and S3 compatible
The Cloud Controller acts as a Meta Scheduler for the Cloud Infrastructure and determines which infrastructure to use.
The Cloud Controller collects resource information from Cluster Controllers
The Cloud Controller runs per default on same machine as Walrus und the Storage Controller.
The Cloud Controller acts as the main Element for a Eucalyptus Cloud. Each Eucalyptus-based Cloud starts with the Cloud Controller. Different Zones or Regions are realized with a Cluster Controller. There is exactly one Cloud Controller.
The Cluster Controller (CC) comes next in hierarchy after the Cloud Controller (CLC). There is exactly one Cluster Controller per location. A location could be compared to an Availability Zone within a Region in Amazon Web Services. The Cluster Controller is basically in charge of receiving requests from the Cloud Controller to deploy new virtual Instances. The Cluster Controller decides which Node is used for the new virtual Instance. The Cluster Controller also maintains virtual Networks available to the instances and collects information about the Node Controllers registered. This information is reported to the Cloud Controller. Each Cluster can have exactly one Cluster Controller.
When a new Instance is started, the Cloud Controller is instructed with the Image, Instance Type and Instance Number. The Cloud Controller looks up a Cluster Controller with enough available resources and selects one to start the instance. The Cloud Controller now itself looks up Node Controllers with enough resource availability and instructs the Node Controller to launch a new virtual Instance. If the Image requested is not available on the Node, the Node Controller looks up the Image by asking the Cloud Controller. The Cloud Controller now provides the Image via Walrus to the Node.
The Node Controller is the lowest Level in the Eucalyptus Stack. Node Controllers run on each physical instance, where virtual machines should run on. Node Controllers support XEN and KVM for virtualization purposes. A Node Controller is in charge of collecting data on the resources available on each instance. It also reports the utilization of the Node the Cluster Controller, to inform the Cluster Controller about the utilization and availability of the instance. The Node Controller also takes care of Instance life cycle management.
The header image is provided by jar (away for a while) under the creative commons licence.
For Cloud Solutions, Scalability and Elasticity are key requirements. In private Cloud Solutions, this should also be supported, even if scalability and elasticity might has a lower border as we see in the public Cloud. Private Cloud Computing environments basically use dedicated Hardware and resources are not shared. Public Cloud Solutions use resource sharing, which is basically not available in private Cloud Solutions. Scaling applications means that we can add a new instance of Linux or a Windows Server. Elasticity is something “more advanced” to that as described by Reuven Cohen, an opinion leader in Cloud Computing (Cohen, 2010). Reuven describes scalability as the possibility to “grow to the demands of the users on a platform” whereas he states that elasticity is something that reflects real-time conditions. A platform might have millions of users, but if this platform is only available in the United States, there might be significant fewer load on the servers during night. The load will be much higher at peak times and elasticity means that unnecessary instances are shut down if the load is lower or that new instances are started if the load is higher. Elasticity is something very important to self Service Platforms, since they basically exist within an enterprise environment. Demand might change over time as not all enterprises act globally and even if they do, different platforms are used in a different manner. Let’s look back to the marketing department introduced earlier; especially in marketing, different groups of users are targeted and it is about targeting regions individually. What works well for customers in the United Kingdom might not work for customers in France and therefore, the website(s) might be different. That makes elasticity important since unused instances can be shut down to use the now free instances for other applications and services. (Owens, 2010) defines Elasticity as „the golden nugget of Cloud Computing“ and a key inhibitor to move to Cloud Environments. A very similar definition on what Cohen defined as elasticity is also provided by the National Institute of Standards and Technology (Mell & Grance , 2011):
elastictiy and scalability for self service platforms (C) Polycart
“Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.” – (Mell & Grance , 2011)
As stated in the beginning of this section, the hardware available to run these services is not infinite and it is much lower as we in public Cloud Solutions. Better utilization of the Datacenter can now enable less critical tasks to be run overnight and use free instances. The IT department could even offer them at lower prices, as we can already see them with spot instances on Amazon Web Services, a popular public Cloud provider (Amazon Web Services, Inc, 2012). A possible use-case could be the research department, which calculates non time-critical tasks during night and saves money by doing so. Since self-Service platforms should be easy to use, most of the elasticity has to be handled by the platform. The IT-department would only set a quota of how many instances are available for a specific service or application and set the rules and boundaries for elasticity. The consumer (or customer) only starts the new service or application and don’t have to care about scaling and elasticity issues, since it should be easy to use.
http://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.png00Mario Meir-Huberhttp://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.pngMario Meir-Huber2013-05-14 17:22:542013-05-14 17:22:54Self service IT Requirements: Scalability and elasticity
CloudVane.com is a popular platform where articles about cloud computing and big data are published. It is listed as the Top 100 Blogs by the Cloud Computing Journal and I often get free event passes for global events.
If you know a lot about the cloud and you want to reach a broader audience, feel free to contact me and start blogging about Cloud Computing today at CloudVane.com.
As CloudVane is a non-commercial site, I can’t pay anything for your efforts – however, you will reach a large audience and increase your visibility within the Cloud area. Whenever I get event invites, I will do my best to distribute that to authors writing at CloudVane.
Interested? Send me an E-Mail: email@example.com. You should indicate your experience with Cloud Computing. Good english skills are mandatory.
Looking forward to hearing from you,
http://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.png00Mario Meir-Huberhttp://cloudvane.net/wp-content/uploads/2019/08/cloudvane_small-300x188.pngMario Meir-Huber2013-05-14 11:01:262013-05-14 11:01:26Be part of the community – write about your favourite cloud/big data topic!
This post is part of the Open Source Cloud Computing series. For an Overview, please click on the Tag.
Eucalyptus was developed at the University of California, Santa Barbara (UCSB) and is provided under the GNU GLP v3 Open Source License. The name Eucalyptus stands for “Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems”. Its main target is to enable the execution and control of virtual instances with Xen or KVM under Linux and to provide an API that is compatible to Amazon Web Services (AWS). Since Eucalyptus is basically built upon the Amazon APIs, it is great for hybrid Cloud Solutions. The first version of Eucalyptus was released in 2008.
Each Eucalyptus component runs as UNIX service and communication between the components is based on SOAP Web services. Eucalyptus infrastructure may consist of one or more locations, which represent different datacenters. Eucalyptus consists the Cloud Controller, Cluster Controller, Node Controller, Walrus and the Storage Controller. The Platform provides Tools that are called “Euca2ools”, which are written in Python. The command-line tools distributed by Amazon Web Services inspire Euca2ools. There are two major Tools:
api-tools (Command Line interface to EC2)
ami-tools (Command Line interface to work with Amazon Machine Image)
With Euca2ools, it is possible to:
Do queries on availability zones (i.e. clusters in Eucalyptus)
Do SSH key management (add, list, delete)
Manage virtual Instances (start, list, stop, reboot, get console output)
Configure and Manage Security groups
Configure and Manage Volumes and snapshots (attach, list, detach, create, bundle, delete)
Manage IP addresses (allocate, associate, list, release)
All Configuration Elements for Eucalyptus are stored in a config-file as Key-Value Pairs. To start Eucalyptus, the configuration must be finished. Eucalyptus needs to connect to Clients (End Users) and Cloud Components (CC, Walrus, etc.). Therefore, network management is essential. Eucalyptus knows the following networking topologies:
Managed Mode. With Manged Mode, Eucalyptus provides all Networking Features such asVM Network Isolation, Security Groups, Elastic IPs and Metadata Service. A Cluster Controller must be in the same broadcasting Domain as the Node Controllers with Managed Mode. Furthermore, all Cluster and Node Controllers must be configured.
Managed Mode without VLAN. This is basically the same as Managed, but no VLAN is used. The Connectivity must be made by Ethernet and all Cluster Controllers and Node Controllers must be in the same Broadcast Domain.
System Mode. Eucalyptus mostly stays out of the way in terms of VM networking and basically relies on DHCP service to configure VM networks On all Cluster Controllers, VNET_MODE=”SYSTEM“ and on a Node Controller, a Bridge must be specified.
Static Mode. Eucalyptus DHCP Server „issues“ the Network Configuration. Nodes must be configured with VNET_MODE=”STATIC”.