Infrastructure Monitoring: Private Datacenter to AWS-Based Public Cloud
SevOne excels at monitoring hybrid cloud scenarios; in this demo, our solution will be monitoring a private data center and an AWS-Based Public Cloud.
Hello everybody and welcome to this SevOne demonstration. In this demonstration we are going to go over how SevOne can monitor a hybrid cloud scenario. In this case it is going to be monitoring both a private data center as well as the Amazon Web Service Public Cloud.
Now just some background on this demonstration what we are doing is we are hosting an internal Wiki solution that is both internal and external. The internal section is hosted locally at our Reston data center in Virginia. The AWS instance is used by the regional employees as well as customers trying to access it outside of our local data center.
The idea behind the deployment is that it's going to segment the network traffic, as well as provide low latency access to users no matter whether they are internal or external. The Reston data center serves as our primary data center, but what we are doing is we currently use full direct replication between both our Reston data center and our San Francisco, California data center. This allows us to provide business connectivity in the event of a disaster; whether in Reston or San Francisco. There is constant replication between both Reston and San Francisco as if the end user won't notice any difference between the internal Wiki, no matter where they access it.
What I am going to do is I am going to go ahead and switch to our demo system here. And what you'll see is just another representation of what I just went over inside the power point slides. We have our three connections our primary being Reston, our secondary being San Francisco, and our third being the cloud AWS, and they all connect at the same firewall. We are also monitoring both our wireless infrastructure, as well as our wired infrastructure because, whether you access it through wi-fi or through direct connection, we need to make sure that we understand how both connections are behaving.
And then below that is our Reston servers, which is our main data center. So we need to know how that is performing, as well as our cloud deployment to make sure that we're able to replicate between the cloud as well as our Reston data center or our San Francisco data center, so that the end user doesn't notice any difference, no matter where they log into the internal Wiki.
So what I'm going to do is I'm going to go ahead and dive deeper into our AWS cloud here to show you some of the metrics that we can pull off that. I'm just gonna go in, clicking the node. So this is our dashboard for our AWS cloud deployment. And as you can see we have a simple status map that shows both locations on the map, as well as where they're located and the status at which each one's coming. So you'll notice that we are experiencing some alerts here, the biggest one being we're experiencing a critical alert, which is being shown by our alerts table here, that we are bringing in more bytes than we're supposed to be. So just an easy, concise way to figure out what's going on inside your cloud deployment.
One of the important things that we're really doing between our AWS cloud and our Reston and San Francisco data centers, we're doing synthetic connection tests between both the Reston data center and the cloud, as well as our San Francisco data center and the cloud, the idea being that if you cannot connect to the cloud there will not be direct replication. And that will be a major issue. So we need to make sure that there's a connection between them.
So really, what we're doing here, and this is one of the things that makes SevOne so unique is that we're able to run all different types of metrics on one dashboard. At the top, you saw that we had status maps and alerts. We're using a type of technology that was AppNeta to do connection testing between our Reston data center and the cloud. So you can see that we have precise metrics on the connection time, the last poll, and the current poll, as well as what's going on. We're also doing any type of data loss between the cloud and Reston, using our AppNeta testing and Reston to cloud, using IP SLA response codes.
Now, directly below that we return to the normal IP SLA test. Our Reston to cloud was using, the type of technology was AppNeta, which can sometimes provide more detail, but there's also a Cisco testing known as IP SLA. So what this is doing is this is doing the exact same testing, but just using a different poller. So we are now using our IP SLA poller to determine response times between our San Francisco data center and the cloud. As well as the availability to access the cloud from the San Francisco data center, as well as any response codes that would have been kicked back from the connection from our San Francisco data center to the cloud.
Now, below this is just CPU statistics. Depending on how you use your Amazon Web Service, in this case, there could be other metrics, like amount of credits remaining, but in this case we're just using general CPU utilization, how much utilization is currently available on our Amazon Web Service storage here. It shows all the spikes as we go up and down over a period of time. And if you wanted to dig down deeper into a specific section of this, it's as simple as just clicking up in the graph actions, taking a small section, and you can get a better understanding of what exactly is happening during that small period of time.
So you can see that we are spiking up to a hundred percent at certain periods of time and then what's happening is they're coming back down. So either we are replicating a new Amazon Web Service and providing us with more storage or the storage is being removed and we're adding more later.
Now below that is more storage statistics, specifically volume writes. So typically the way Amazon bills you for AWS is the amount of read and writes put onto the Amazon Web Service. So these are very important metrics to have. You're able to see the amount of read and writes on there, and as I mentioned, that's what they charge you on. This is just a basic metric of how many read and writes have happened over the last week, as well as the queue length volume because if your queue backs up too long, especially in this instance, you will not see that direct replication between the Reston data center and the San Francisco data center and the cloud. So there will be a difference of appearance depending on where you log into it, so that's a very important metric to have.
And then mention these are just network in and out bytes. Once again, this is how Amazon bills you, so you can just see again the amount of bandwidth that is going back and forth between Amazon. Because again, transfer of data is also another way that Amazon bills you, so it would be good to know how much data is being transferred between the cloud and your data centers.
Now just like with the IP SLA and the AppNeta we are able to put lots of different types of metrics on one concise dashboard. Here you'll see this is an exact flow report of exactly what is being transferred between the data centers and the cloud, so you can see exactly what is being moved between the two locations. That way if something is being moved that shouldn't be, you can get a very quick and concise view, as to what is occurring inside those transfers.
And lastly, these are very specific Amazon KPI's that only comes with Amazon Web Service. Not only are we using the SevOne poller to poll some of these metrics between the cloud and the Reston data center, we also need integration with Amazon Web Service to get very specific KPI's that only exist on Amazon. So instead of needing a network monitoring tool and the Amazon Web Service monitoring too, with SevOne you can do it all in one concise place. So you'll see that we've had no failed status checks over the last week, which is always a good thing to see because if we have any failed checks, that means there's a problem going on.
As well as using not only Amazon's capacity planning but you can use our capacity planning to determine when you're going to run out of storage, as well as what it's going to cost you to run it. So you can see that using Amazon's E2C estimated charges that over the past week, you can see that it's going to cost us more and more to use the Amazon Web Service because we're putting more and more things on the cloud, as well as the amount of data transfers, cost per data transfer, and the estimated charges. So this is a way to keep track of your spending, to make sure that you don't go over what you've estimated in terms of your budget for the Amazon Web Service.
So not only can we poll normal metrics using SevOne, we also can poll very specific Amazon Web Service metrics and put them all in one easy, concise place for you guys to access and help manage your hybrid cloud.