Tag Archive

Below you'll find a list of all posts that have been tagged as "datacenter"
blogImage

Why Hyper-Converged is best solution for Storage, Networking, Virtualization?

The storage industry is evolving, albeit with an increasing need of ease of managing datacentres. With the advent of hyper-converged solutions, there has been a significant advantage in running datacentres. In this article, we will discuss datacentre related scenarios which can be circumvented with a hyper-converged solution. Scenario 1: The need to build a data centre which requires storage, networking and virtualization. Scenario 2: System failures in the storage system; considering that for the storage industry, triaging with failures is very tedious process. Solution The efficient solution to the above problem is to have a hyper-converged solution which can be useful to provide a one stop resolution to your storage, networking and virtualization requirements. Let’s discuss this in detail. Hyper-converged solutions are sold as a single deck box having in-built storage, networking and virtualization solutions. So considering the first scenario, where you want to build a datacentre automation system, you need to rely on other vendors for solutions. Hyper-converged is a highly scalable platform that gives you everything in a single deck which seamlessly integrates your SAN, servers and virtualization software. Considering the second scenario of system failure, you may not necessarily be aware of the root cause, and triaging failure usually needs the involvement of vendors. Instead, if you opt for a hyper-converged solution, you get to know about the root-cause of any failure, as hyper-converged infrastructures provide single page application that offer easy fault detection. Cost optimization, data optimization, data rebalancing and high availability are also some key features which are provided by Hyper-Converged Solutions. Most hyper-converged solutions provide 24*7 data availability, greatly reducing downtime and data-loss possibilities. Hence most hyper-converged solutions provide zero RPO (Recovery Point Objective) which corresponds to no data loss and zero RTO (Recovery Time Objective) which corresponds to no downtime. In the storage industry, data protection is very crucial, and hyper converged solutions provide efficient answers for them. Also disaster recovery and data protection is a very important aspect for storage systems. With the help of hyper-converged solutions, disaster recovery and data protection are managed very well. Hyper-converged solutions come with bare metal along with pre-installed operating systems which provide ease of management and avoid any compatibility issues. Aziro (formerly MSys Technologies) specializes in Storage, Networking, Virtualization and Networking and is a global leader in providing services to build hyper converged solutions. Aziro (formerly MSys Technologies) can play an important role in providing the best in class solutions to builds hyper-converged solution for your organisation.

Aziro Marketing

blogImage

Federated Data Services through Storage Virtualization

When one talks about virtualization, the immediate thought that comes to mind is about server/ host virtualization otherwise understood from the virtualization offerings from the likes of VMware, Citrix, Microsoft, etc. However, there is a not-so-explored & not much known data center technology that can contribute significantly to a modern (future) data center. When we talk of real time cloud application deployment (access anywhere) with enterprise workloads, there should be something more that the Infrastructure should support, to enable effective consolidation and management of storage/ host infrastructure across a data center.This article aims to introduce Storage Virtualization (SV) as a technology and the role this can play in enabling federated data services use cases. Aziro (formerly MSys Technologies) also has been a leading virtualization services provider working on the same technology.The Need for Storage VirtualizationTraditional data centers are largely FC-SAN based, where monoliths of huge enterprise storage arrays are hosted, deployed, configured, and managed but with niche expertise. Most of mission critical applications of the world run on such data centers (DC). EMC (Dell EMC), NetApp, IBM, HP (HPE), etc. are a few major players in this arena. The appliances these companies have built are tested and proven on the field for the reliability, efficiency and availability across various workloads.However, the major constraint of an IT investor of the modern times is related to the DC/ DR manageability and upgradability, more in the context of upcoming products with alternate technologies such as hyper converged storage; than defy the storage array based implementations. With vendor lock-in’s, rigid & propriety storage management API’s/ UI’s, it is a cumbersome process to think of an idea of having heterogeneous storage arrays with various vendors in a DC. Also, it poses the challenge of having skilled administrators who are well-versed on all different product implementations and management.Before it was a hyper-converged storage, the storage majors ventured to innovate an idea that could possibly solve this problem. This is how Storage Virtualization was born – where a way was envisaged to have heterogeneous storage arrays in a DC but still could seamlessly migrate data/ applications between them through a unified management interface. Not just that, the thrust was to see a bigger picture of application continuity to data center business continuity scaling up the scope of the high availability picture.What is Storage Virtualization?Storage virtualization (SV) is the pooling of physical storage from multiple storage arrays or appliances into what appears to be a single storage appliance that can be managed from a central console/ unified storage management application. Storage Virtualization could be an appliance hosted between the host and the target storage or could be just a software VM.Some popular SV SAN solutions available in the market are IBM SVC, EMC VPlex, NetApp V-series, etc.Use case & Implementation – How does it work?Let’s look at a practical data center use case of a heterogeneous data center, where there are 9 enterprise storage arrays, say 2 nos. of Dell EMC VMAX, 1 nos. of HPE 3PAR, 1 nos. of IBM V7000 & 5 nos. of EMC Clariion CX300. Consider that all legacy applications are currently hosted in EMC Clariion array and all the mission critical applications are hosted independently in EMC/ HPE/ IBM arrays. Let’s assume that the total data center storage requirements are already met and with the current infrastructure, it can easily support the requirement for the next 5 years. Consider, just between HPE, EMC and IBM arrays, we have sufficient storage space to accommodate the legacy applications as well. However, there isn’t a way yet to manage such a migration or a consolidated management of all different storage devices.Now, let’s look at some of the use case requirements/ consolidation challenges that a storage consultant should solve:Fully phase out Legacy CX300 Arrays and migrate all the legacy applications to one of enterprise arrays say, IBM V7000, but with minimum down time.Setting up a new data center, DC2 about 15 miles away and moving 2 of the enterprise arrays, say 2* EMC VMAX arrays to the new site and host this as an active-active data center/ disaster recovery site for former DC (DC1).The current site, DC1 should become DR site for the new DC, DC2 however should actively engage I/O and business should continue. (Synchronous use case)Management overhead of using products from 3 different vendors should reduce and should be simplified.The entire cycle of change should happen with minimum downtime except for the case of physical movement/ configuration of VMAX arrays to the new site.The architecture should be scalable for data requirements of next 5 years in such a way that new storage arrays from existing or new vendors can be added with no downtime/ disruption.The DC & DR sites are mutually responsive to each other during an unforeseen disaster and are highly available.Solution IllustrationThis is a classic case for Storage Virtualization Solution. An SV solution is typically an appliance with software & intelligence that is sandwiched between the initiator (hosts) and the target (heterogeneous storage arrays). For the initiator, the SV is the target and for the target, the SV becomes the initiator. All the storage disks from the target (with/ without data) appear as a bunch of unclaimed volumes in the SV. As far as hosts are concerned, they appear to the SV as unmapped initiators unregistered. Storage- Initiator groups are created (registered) in the SV which can be modified/ changed on the fly giving flexible host migration at the time of server disaster.There are different SV solutions available from vendors such as EMC VPlex that can help cases of local DC migration as well as migration between sites / DC’s. Let’s see how the solution unfolds to our use case requirements.Storage from both legacy array and the new array once configured to access the hosts through an SV solution, the storage disks/ LUNs appear as pool of storage at the DV interface. The SV solutions encapsulates the storage so that data migration between both the arrays can happen non-disruptively. Vendor1- Vendor2 replications are challenging and often disruptive.SV solutions are configured in a fully HA configuration providing fault tolerance at every level (device, storage, array, switch, etc.).Across site SV solution such as EMC VPlex Metro can perform a site-site data mirroring (synchronous) that too which both the sites are fully in active-active IO configuration.The entire configuration done through HA Switches provides option to scale to add existing/ new vendor storage arrays as well new Hosts/ Initiators with zero down time.The entire solution be it at local DC level or multi-site would be fully manageable through a common management UI/ Interface reducing the dependence on skilled storage administrators who are vendor specific.A SV solution consolidates the entire storage and host infrastructure to a common platform simplifying the deployment and management. Also, this sets a new dimension to hyper-converged storage infrastructure to be scaled across sites.A SV solution is agnostic, to the host and storage giving diversity of deployment options. For e.g. various host hardware, operating systems, etc.All the features of a storage array are complimented to its full potential along with superior consolidation across Storage/ sites with additional availability/ reliability features.Solutions like VMware vMotion does help in site- site migration, however, an SV solution provides the infrastructure support for that happen at the storage device level that too across sites.ConclusionIt’s just a matter of time, when we will see more efficiently packaged & effectively deployed SV solutions. Perhaps, it could be called software defined SV solution that can be hosted on a VM instead of an appliance. Storage consolidation is a persistent problem, more so in the modern days, due to the diversity of Sever Virtualization/ SDS Solutions, varieties of Backup and recovery applications/ options available to an IT Administrator. There should be a point where DC should become truly converged where best of every vendor can co-exist in its own space complimenting each other. However, there is a business problem to that wish. For now, we can only explore more on what SV can offer us.

Aziro Marketing

blogImage

How you can Hyperscale your Applications Using Mesos & Marathon

In a previous blog post we have seen what Apache Mesos is and how it helps to create dynamic partitioning of our available resources which results in increased utilization, efficiency, reduced latency, and better ROI. We also discussed how to install, configure and run Mesos and sample frameworks. There is much more to Mesos than above.In this post we will explore and experiment with a close to real-life Mesos cluster running multiple master-slave configurations along with Marathon, a meta-framework that acts as cluster-wide init and control system for long running services. We will set up a 3 Mesos master(s) and 3 Mesos slaves(s), cluster them along with Zookeeper and Marathon, and finally run a Ruby on Rails application on this Mesos cluster. The post will demo scaling up and down of the Rails application with the help of Marathon. We will use Vagrant to set up our nodes inside VirtualBox and will link the relevant Vagrantfile later in this post.To follow this guide you will need to obtain the binaries for Ubuntu 14.04 (64 bit arch) (Trusty)Apache MesosMarathonApache ZookeeperRuby / RailsVirtualBoxVagrantVagrant Pluginsvagrant-hostsvagrant-cachierLet me briefly explain what Marathon and Zookeeper are.Marathon is a meta-framework you can use to start other Mesos frameworks or applications (anything that you could launch from your standard shell). So if Mesos is your data center kernel, Marathon is your “init” or “upstart”. Marathon provides an excellent REST API to start, stop and scale your application.Apache Zookeeper is coordination server for distributed systems to maintain configuration information, naming, provide distributed synchronization, and group services. We will use Zookeeper to coordinate between the masters themselves and slaves.For Apache Mesos, Marathon and Zookeeper we will use the excellent packages from Mesosphere, the company behind Marathon. This will save us a lot of time from building the binaries ourselves. Also, we get to leverage bunch of helpers that these packages provide, such as creating required directories, configuration files and templates, startup/shutdown scripts, etc. Our cluster will look like this:The above cluster configuration ensures that the Mesos cluster is highly available because of multiple masters. Leader election, coordination and detection is Zookeeper’s responsibility. Later in this post we will show how all these are configured to work together as a team. Operational Guidelines and High Availability are goodreads to learn and understand more about this topic.InstallationIn each of the nodes we first add Mesosphere APT repositories to repository source lists and relevant keys and update the system.$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF $ echo "deb http://repos.mesosphere.io/ubuntu trusty main" |  sudo tee /etc/apt/sources.list.d/mesosphere.list $ sudo apt-get -y update If you are using some version other than Ubuntu 14.04 then you will have to change the above line accordingly and if you are using some other distribution like CentOS then you will have to use relevant rpm and yum commands. This applies everywhere henceforth.On master nodes:In our configuration, we are running Marathon on the same box as Mesos masters. The folks at Mesosphere have created a meta-package called mesosphere which installs Mesos, marathon and also zookeeper.$ sudo apt-get install mesosphere On slave nodes:On slave nodes, we require only zookeeper and mesos installed. The following command should take care of it.$ sudo apt-get install mesos As mentioned above, installing the above packages will do more that just installing packages. Much of the plumbing work is taken care of for the better. You need not worry if the mandatory “work_dir” has been created in the absence of which Apache Mesos would not run and other such important things. If you want to understand more, extracting scripts from the package and studying them is highly recommended. That is what I did as well.You can save a lot of time if you clone this repository and then run the following command inside your copy.$ vagrant up This command will launch a cluster, set the IPs for all nodes, install all required packages to follow this post. You are now ready to configure your cluster.ConfigurationIn this section we will configure each tool/application one by one. We will start with Zookeeper, then Mesos servers, then Mesos slaves and finally Marathon.ZookeeperLet us stop Apache Zookeeper on all nodes (masters and slaves).$ sudo service zookeeper stop Let us configure Apache Zookeeper on all masters. Do the following steps on each master.Edit /etc/zookeeper/conf/myid on each of the master nodes. Replace the boilerplate text in this file with a unique number (per server) from 1 to 255. These numbers will be the IDs for the servers being controlled by Zookeeper. Lets chose 10, 30 and 50 as IDs for the 3 Mesos master nodes. Save the files after adding 10, 30 and 50 respectively in /etc/zookeeper/conf/myid for the nodes. Here’s what I had to do on the first master node. Same has to be repeated on other nodes with respective IDs.$ echo 10 | sudo tee /etc/zookeeper/conf/myid Next we configure the Zookeeper configuration file ( /etc/zookeeper/conf/zoo.cfg ) for each master node. For the purpose of this blog we are just adding the master node IPs and relevant server IDs that was selected in the previous step.Note the configuration template line below. server.id=host:port1:port2. port1 is used by peer ZooKeeper servers to communicate with each other, and port2 is used for leader election. The recommended values are 2888 and 3888 for port1 and port2 respectively but you can choose to use custom values for your cluster.Assuming that you have chosen the IP range 10.10.20.11-13 for your Mesos servers as mentioned above, edit /etc/zookeeper/conf/zoo.cfg to reflect the following:# /etc/zookeeper/conf/zoo.cfg server.10=10.10.20.11:2888:3888 server.30=10.10.20.12:2888:3888 server.50=10.10.20.13:2888:3888 This file will have many other Zookeeper related configurations which are beyond the scope of this post. If you are using the packages mentioned above, the configuration templates should be a lot of help. Definitely read the comments sections, a lot to learn there.This is a good tutorial on understand fundamentals of Zookeeper. And this document is perhaps the latest and best document to know more about administering Apache Zookeeper, specifically this section is of relevance of what we are doing.All NodesZookeeper Connection DetailsFor all nodes (masters and slaves), we have to set up Zookeeper connection details. This will be stored in /etc/mesos/zk, a configuration file that you will get thanks to the packages. Edit this file on each node and add the following url carefully.#/etc/mesos/zk zk://10.10.20.11:2181,10.10.20.12:2181,10.10.20.13:2181/mesos Port 2181 is Zookeeper’s client port that it listens to for client connections. IP addresses will differ if you have chosen IPs for your servers differently.IP AddressesNext we set up IP address information for all nodes (masters and slaves).Masters$  echo  | sudo tee /etc/mesos-master/ip $ sudo cp /etc/mesos-master/ip /etc/mesos-master/hostname Write the IP of the node in the file. Save and close the file.Slaves$ echo  | sudo tee /etc/mesos-slave/ip $ sudo cp /etc/mesos-slave/ip /etc/mesos-slave/hostname Write the IP of the node in the file. Save and close the file. Keeping the hostname same as IP makes it easier to resolve DNS.If you are using the Mesosphere packages, then you get a bunch of intelligent defaults. One of the most important things you get is a convenient way to pass CLI options to Mesos. All you need to do is create a file with same name as that of the CLI option and put the correct value that you want to pass to Mesos (master or slave). The file needs to be copied to a correct directory. In case of Mesos masters, you need to copy the correct file to /etc/mesos-master and for slaves you should copy the file to /etc/mesos-slave For example: echo 5050 > sudo tee /etc/mesos-slave/port We will see some examples of similar configuration setup below. Here you can find all the CLI options that you can pass to Mesos master/slave.Mesos ServersWe need to set a quorum for the servers. This can be done by editing /etc/mesos-master/quorum and setting it to a correct value. For our case, the quorum value can be 2 or 3. We will use 2 in this post. Quorum is the strict majority. Since we chose 2 as quorum value it means that out of 3 masters, we will definitely need at least 2 master nodes running for our cluster to run properly.We need to stop the slave service on all masters if they are running. If they are not, the following command might give you a harmless warning.$ sudo service mesos-slave stop Then we disable the slave service by setting a manual override.$ echo manual | sudo tee /etc/init/mesos-slave.override Mesos SlavesSimilarly we need to stop the master service on all slaves if they are running. If they are not, the following command might give you a harmless warning. We also set the master and zookeeper service on each slave to manual override.$ sudo service mesos-master stop $ echo manual | sudo tee /etc/init/mesos-master.override $ echo manual | sudo tee /etc/init/zookeeper.override The above .override files are read by upstart on Ubuntu box to start/stop processes. If you are using a different distribution or even Ubuntu 15.04 then you might have to do this differently.MarathonWe can now configure Marathon, for which we need some work to be done. We will configure Marathon only on the server nodes.First create a directory for Marathon configuration.$ sudo mkdir -p /etc/marathon/conf Then like we did before, we will set configuration properties by creating files with same name as that of property to be set and adding the value of the property as the only content of the file (see box above).Marathon binary needs to know the values for –master and –hostname. We can reuse the files that we used for Mesos configuration.$ sudo cp /etc/mesos-master/ip /etc/marathon/conf/hostname $ sudo cp /etc/mesos/zk /etc/marathon/conf/master To make sure Marathon can use Zookeeper, do the following (note the endpoint is different in this case i.e. marathon):$ echo zk://10.10.20.11:2181,10.10.20.12:2181,10.10.20.13:2181/marathon \ | sudo tee /etc/marathon/conf/zk Here you can find all the command line options that you can pass to Marathon.Starting ServicesNow that we have configured our cluster, we can resume all services.Master$ sudo service zookeeper start $ sudo service mesos-master start $ sudo service marathon start Slave$ sudo service mesos-slave start Running Your ApplicationMarathon provides nice Web UI to set up your application. It also provides an excellent REST API to create, launch, scale applications, check health status and more.Go to your Marathon Web UI, if you followed the above instructions then the URL should be one of the Mesos masters on port 8080 ( i.e. http://10.10.20.11:8080 ). Click on “New App” button to deploy a new application. Fill in the details. Application ID is mandatory. Select relevant values for CPU, Memory, Disk Space for your application. For now let number of instances be 1. We will increase them later when we scale up the application in our shiny new cluster.There are a few optional settings that you might have to take care depending on our your slaves are provisioned and configured. For this post, I made sure each slave had Ruby, Ruby related dependencies and Bundler gem were installed. I took care of this when I launched and provisioned the slaves nodes.One of the important optional settings is “Command” that Marathon can execute. Marathon monitors this command and reruns it if it stops for some reason. Thus Marathon claims to fame as “init” and runs long running applications. For this post, I have used the following command (without the quotes).“cd hello && bundle install && RAILS_ENV=production bundle exec unicorn -p 9999” This command reads the Gemfile in the Rails application, installs all the necessary gems required for the application, and then runs the application on port 9999.I am using a sample Ruby On Rails application. I have put the url of the tarred application in the URI field. Marathon understands a few archive/package formats and takes care of unpacking them so we needn’t worry about them. Applications need resources to run properly, URIs can be used for this purpose. Read more about applications and resourceshere.Once you click “Create”, you will see that Marathon starts deploying the Rails application. A slave is selected by Mesos, the application tarball is downloaded, untarred, requirements are installed and the application is run. You can monitor all the above steps by watching the “Sandbox” logs that you should find on Mesos main web UI page. When the state of task will change from “Staging” to “Running” we have a Rails application run via Marathon on a Mesos slave node. Hurrah!If you followed the steps from above, and you read the “Sandbox” logs you know the IP of the node where the application was deployed. Navigate to the SLAVE_NODE_IP:9999 to see your rails application running. Scaling Your ApplicationAll good but how do we scale? After all, the idea is for our application to reach web scale and become the next Twitter, and this post is all about scaling application with Mesos and Marathon. So this is going to be difficult! Scaling up/down is difficult but not when you have Mesos and Marathon for company. Navigate to the application page on Marathon UI. You should see a button that says “Scale”. Click on it and increase the number to 2 or 3 or whatever you prefer (assuming that you have that many slave nodes). In this post we have 3 slave nodes, so I can choose 2 or 3. I chose 3. And voila! The application is deployed seamlessly to the other two nodes just like it was deployed to the first node. You can see for yourself by navigating to SLAVE_NODE_IP:9999 where SLAVE_NODE_IP will be the IP of the slave where the application was deployed. And there you go, you have your application running on multiple nodes.It would be trivial to put these IPs behind a load-balancer and a reverse proxy so that access to your application is as simple as possible. Graceful Degradation (and vice versa)Sometimes nodes in your clusters go down for one reason or other. Very often we get an email from your IaaS provider that your node will be retired in few days time and at other times a node dies before you could figure out what happened. When such inevitable things happen and the node in question is part of the cluster running the application, the dynamic duo of Mesos and Marathon have your back. The system will detect the failure, will de-register the slave and deploy the application to a different slave available in the cluster. You could tie it up with your IaaS-provided scaling option and spawn required number of new slave nodes as a part of your cluster which once registered with the Mesos cluster can run your application.Marathon REST APIAlthough we have used the Web UI to add a new application and scale it. We could have done the same (and much more) using REST API and thus do Marathon operations via some program or scripts. Here’s an simple example that will scale the application to 2 instances. Use any REST client or just curl to make a PUT request to the application ID, in our case http://10.10.20.11:8080/v2/apps/rails-app-on-mesos-marathon with the following JSON data as payload. You will notice that Marathon deploys the application to another instance if there was only 1 instance before.{    "instances" : 2 } You can do much more than above, do health checks, add/suspend/kill/scale applications etc. This can become a complete blog post in itself and will be dealt at a later time.ConclusionScaling your application becomes as easy as pressing buttons with a combination of Mesos and Marathon. Setting up a cluster can become almost trivial once you get your requirements in place and ideally automate the configuration and provisioning of your nodes. For this post, I relied on simple Vagrantfile and a shell script that provision the system. Later I configured the system by hand as per above steps. Using Chef or alike would make the configuration step a single command work. In fact there are a few open-source projects that are already very successful and do just that. I have played witheverpeace/vagrant-mesos and it is an excellent starting point. Reading the code from these projects will help you understand a lot about building and configuring clusters with Mesos.There are other projects that do similar things like Marathon and sometimes more. I definitely would like to mention Apache Aurora and HubSpot’s Singularity.

Aziro Marketing

blogImage

So You Want to Build Your Own Data Center?

In today’s internet-of-things world, companies run their applications 24×7, and this generally results in a lot of users or data. This data needs to be stored, analyzed, and post-processed; in essence, some action needs to be taken on it. We are looking at huge fluctuating workloads. The scale of operations is enormous, and to handle this kind of mammoth operations, clusters are built. In the age of commodity hardware, clusters are easy to build, but clusters with specific software stack that could do only one type of task (static partitioning of resources) lead to less optimal resource utilization, because it is possible that no task of that type is running at a given time.For example, Jenkins slaves in a CI cluster could be sitting idle at night or during a common vacation time when developers are not pushing code. But let’s say, when product release time is near, it might so happen that developers are pushing and hacking away at code so frequently that the build queue becomes longer due to the need for slaves to run the CI jobs. Both the situations are undesirable and reduce the efficiency and ROI of the company.Dynamic partitioning of resources is the solution to fix the above issue. Here, you pool your resources (CPU, memory, IO, etc.) such that nodes from your cluster act as one huge computer. Based on your current requirement, resources are allocated to the task that needs it. So the same pool of hardware runs your Hadoop, MySQL, Jenkins, and Storm jobs. You can call this “node abstraction.” Thus achieve diverse cluster computing on commodity hardware by fine-grained resource sharing. To put it simply, different distributed applications run on the same cluster.Google has mastered this kind of cluster computing for almost 2 decades now. The outside world does not know much about their project known as Borg or its successor, Omega. Ben Hindman, an American entrepreneur, and a group of researchers from UC Berkeley came up with an open-source solution inspired by Borg and Omega.Enter Mesos!What Is Mesos?Mesos is a scalable and distributed resource manager designed to manage resources for data centers.Mesos can be thought of as “distributed kernel” that achieves resource sharing via APIs in various languages (C++, Python, Go, etc.) Mesos relies on cgroups to do process isolation on top of distributed file systems (e.g., HDFS). Using Mesos you can create and run clusters running heterogeneous tasks. Let us see what it is all about and some fundamentals on getting Mesos up and running.Basic Terminology and ArchitectureMesos follows the master-slave architecture. It can also have multiple masters and slaves. Multi-master architecture makes Mesos fault-tolerant. The leader is elected through ZooKeeper.A Mesos application, or in Mesos parlance a “framework,” is a combination of a scheduler and an executor. Framework’s scheduler is responsible for registering with the Mesos master and also for accepting or rejecting resource offers from the Mesos master. An executor is a process running on Mesos slave that actually runs the task. Mesos has a distributed two-way scheduling called resource offer. A “resource offer” can be thought of as a two-step process, where initially a message from the Mesos master is sent to a particular framework on a Mesos slave about what resources (CPU, memory, IO etc) are available to it. The framework decides which offers it should accept or reject and which tasks to run on them.A task could be a Jenkins job inside a Jenkins slave, a Hadoop MapReduce job, or even a long-running service like a Rails application. Tasks run in isolated environment which can be achieved via cgroups, Linux containers, or even Zones on Solaris. Since Mesos v0.20.0, native Docker support has been added as well.Examples of useful existing frameworks include Storm, Spark, Hadoop, Jenkins, etc. Custom frameworks can be written on the API provided by Mesos kernel in various languages–C++, Python, Java, etc.Image credit: Mesos documentationA Mesos slave informs Mesos master about its available resources that the slave is ready to share. The Mesos master based on allocation policy makes “resource offers” to a framework. The framework’s scheduler decides whether or not to accept the offers. Once accepted, the framework sends a task description (and its resource requirements) to the Mesos master it needs to run. The Mesos master then sends these tasks to the Mesos slave to be executed on the slave by the framework’s executor. Finally the framework’s executor launches the task. Once the task is complete and the Mesos slave is idle, it reports back to the Mesos master about the freed resources.Mesos is being used by Twitter for many of their services including analytics, typeahead, etc. Many other companies who have large cluster and big data requirements like Airbnb, Atlassian, Ebay, Netflix, and others use Mesos.What Do You Get With Mesos?Arguably the most important feature that you can get out of Mesos would be “resource isolation.” This resource can be CPU, memory, etc. Mesos allows running multiple distributed applications on the same cluster, and this gives us increased utilization, efficiency, reduced latency, and better ROI.How to Build and Run Mesos on Your Local Machine?Enough with the theory! Now let us do fun bits of actually building the latest Mesos from Git and running Mesos and test frameworks. The below steps assume you are running Ubuntu 14.04 LTS.* Get Mesos     git clone https://git-wip-us.apache.org/repos/asf/mesos.git * Install dependencies    sudo apt-get update    sudo apt-get install build-essential openjdk-6-jdk python-dev python-boto libcurl4-nss-dev libsasl2-dev maven libapr1-dev libsvn-dev autoconf libtool * Build Mesos    cd mesos    ./bootstrap    mkdir build && cd build    ../configure    makeof things can be configured, enabled, or disabled before building Mesos. Most importantly, you can choose where you want to install Mesos by passing the directory to “–prefix” at the configure step. You can optionally use system-installed versions for ZooKeeper, gmock, protocol buffers, etc., instead of building them and thus save some time. You can also save some time by disabling language bindings that you might not need.As a general rule it would be nice to use a beefy machine with at least 8 GB RAM and fast enough processor if you are building Mesos locally on your test machine.* Run tests    make checkNote that these tests take a lot of time to build (if they are not built by default) and run.* Install Mesos    make installThis is an optional step; if you ignore it then you can run Mesos from the build directory you created earlier. But if you choose to install it, it will be installed in the $PREFIX that you chose during the configure step. If you do not provide custom $PREFIX, it will be installed to /usr/local/bin.* Prepare the system    sudo mkdir /var/lib/mesos    sudo chown  /var/lib/mesosThe above two steps are mandatory. Mesos will throw an error if the directory is not there or permissions and ownership are not set correctly. You can chose some other directory but you have to provide the same as work_dir. Refer the next command. * Run Mesos Master    ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesosIt is mandatory to pass –work_dir with correct directory as the value to the command line switch. Mesos master uses it for replicated log registry.* Run Mesos Slave    ./bin/mesos-slave.sh --master=127.0.0.1:5050And voila! Now you have a Mesos master and Mesos slave running.Mesos by itself is incomplete. It uses frameworks to run distributed applications. Let’s run a sample framework. Mesos comes with a bunch of example frameworks located in “mesos/src/examples” folder of your mesos Git clone. For this article, I will run the Python framework that you should find in “mesos/src/examples/python”.You can play with the example code for more fun and profit. See what happens when you increase the value of TOTAL_TASKS in “mesos/src/examples/python/test_framework.py”. Or you could try to simulate different duration taken by tasks to execute by inserting a random amount of sleep in run_task() method inside “mesos/src/examples/python/test_executor.py”.* Run frameworks    cd mesos/build    ./src/examples/python/test-framework 127.0.0.1:5050Assuming that you have followed the above steps you can view the Mesos Dashboard at http://127.0.0.1:5050. Here is how it looked on our test box. ConclusionMarathon, a meta-framework on top of Mesos, is distributed init.d. It takes care of starting, stopping, restarting services, etc. Chronos, a scheduler, think of it as distributed and fault-tolerant cron (*nix scheduler), which takes care of scheduling tasks. Mesos even has a CLI tool (pip install mesos.cli), using which you can interact (tail, cat, find, ls, ps, etc.) with your Mesos cluster via command line and feel geeky about it. A lot can be achieved with Mesos, Marathon, and Chronos together. But more about these in a later post. I hope you have enjoyed reading about Mesos. Please share your questions through the comments.

Aziro Marketing

EXPLORE ALL TAGS
2019 dockercon
Advanced analytics
Agentic AI
agile
AI
AI ML
AIOps
Amazon Aws
Amazon EC2
Analytics
Analytics tools
AndroidThings
Anomaly Detection
Anomaly monitor
Ansible Test Automation
apache
apache8
Apache Spark RDD
app containerization
application containerization
applications
Application Security
application testing
artificial intelligence
asynchronous replication
automate
automation
automation testing
Autonomous Storage
AWS Lambda
Aziro
Aziro Technologies
big data
Big Data Analytics
big data pipeline
Big Data QA
Big Data Tester
Big Data Testing
bitcoin
blockchain
blog
bluetooth
buildroot
business intelligence
busybox
chef
ci/cd
CI/CD security
cloud
Cloud Analytics
cloud computing
Cloud Cost Optimization
cloud devops
Cloud Infrastructure
Cloud Interoperability
Cloud Native Solution
Cloud Security
cloudstack
cloud storage
Cloud Storage Data
Cloud Storage Security
Codeless Automation
Cognitive analytics
Configuration Management
connected homes
container
Containers
container world 2019
container world conference
continuous-delivery
continuous deployment
continuous integration
Coronavirus
Covid-19
cryptocurrency
cyber security
data-analytics
data backup and recovery
datacenter
data protection
data replication
data-security
data-storage
deep learning
demo
Descriptive analytics
Descriptive analytics tools
development
devops
devops agile
devops automation
DEVOPS CERTIFICATION
devops monitoring
DevOps QA
DevOps Security
DevOps testing
DevSecOps
Digital Transformation
disaster recovery
DMA
docker
dockercon
dockercon 2019
dockercon 2019 san francisco
dockercon usa 2019
docker swarm
DRaaS
edge computing
Embedded AI
embedded-systems
end-to-end-test-automation
FaaS
finance
fintech
FIrebase
flash memory
flash memory summit
FMS2017
GDPR faqs
Glass-Box AI
golang
GraphQL
graphql vs rest
gui testing
habitat
hadoop
hardware-providers
healthcare
Heartfullness
High Performance Computing
Holistic Life
HPC
Hybrid-Cloud
hyper-converged
hyper-v
IaaS
IaaS Security
icinga
icinga for monitoring
Image Recognition 2024
infographic
InSpec
internet-of-things
investing
iot
iot application
iot testing
java 8 streams
javascript
jenkins
KubeCon
kubernetes
kubernetesday
kubernetesday bangalore
libstorage
linux
litecoin
log analytics
Log mining
Low-Code
Low-Code No-Code Platforms
Loyalty
machine-learning
Meditation
Microservices
migration
Mindfulness
ML
mobile-application-testing
mobile-automation-testing
monitoring tools
Mutli-Cloud
network
network file storage
new features
NFS
NVMe
NVMEof
NVMes
Online Education
opensource
openstack
opscode-2
OSS
others
Paas
PDLC
Positivty
predictive analytics
Predictive analytics tools
prescriptive analysis
private-cloud
product sustenance
programming language
public cloud
qa
qa automation
quality-assurance
Rapid Application Development
raspberry pi
RDMA
real time analytics
realtime analytics platforms
Real-time data analytics
Recovery
Recovery as a service
recovery as service
rsa
rsa 2019
rsa 2019 san francisco
rsac 2018
rsa conference
rsa conference 2019
rsa usa 2019
SaaS Security
san francisco
SDC India 2019
SDDC
security
Security Monitoring
Selenium Test Automation
selenium testng
serverless
Serverless Computing
Site Reliability Engineering
smart homes
smart mirror
SNIA
snia india 2019
SNIA SDC 2019
SNIA SDC INDIA
SNIA SDC USA
software
software defined storage
software-testing
software testing trends
software testing trends 2019
SRE
STaaS
storage
storage events
storage replication
Storage Trends 2018
storage virtualization
support
Synchronous Replication
technology
tech support
test-automation
Testing
testing automation tools
thought leadership articles
trends
tutorials
ui automation testing
ui testing
ui testing automation
vCenter Operations Manager
vCOPS
virtualization
VMware
vmworld
VMworld 2019
vmworld 2019 san francisco
VMworld 2019 US
vROM
Web Automation Testing
web test automation
WFH

LET'S ENGINEER

Your Next Product Breakthrough

Book a Free 30-minute Meeting with our technology experts.

Aziro has been a true engineering partner in our digital transformation journey. Their AI-native approach and deep technical expertise helped us modernize our infrastructure and accelerate product delivery without compromising quality. The collaboration has been seamless, efficient, and outcome-driven.

Customer Placeholder
CTO

Fortune 500 company