Allen Smith: I’m sure I don’t have to tell you guys, the smart phone explosion is here on this right tablet. These are really actually little old of numbers, but smart phones and tablets are out selling PCs and everybody wants to use those to improve their productivity.

Vendors in both our active staff are trying to catch up with our users and what they can do. I’m sure you guys are aware of that or you wouldn’t be on this call. We understand the problems here.

So why Adcap’s mobility solutions, right? It’s comprehensive; we’ve been doing this for a long time. We’ve got expertise in networking and applications, communications, and security. Our workforce itself is at least 80% mobile so we use this on a daily basis. We have a pretty successful track record of deploying these things and new technology.

We use these things internally; we understand how they operate with each other. We know how to support the solution and we know how to work with our vendors to repeatedly improve our solution.

And finally, what is the goal? What is the goal of anybody’s mobility solution? What is you guys’ goal for BYOD?

It’s to maximize your mobile workforce. You want to improve your competitiveness. You want to be able to respond better. You want to be able to increase your productivity. Along with that we have to maximize the availability of that; we have to keep our systems running and make sure we don’t lose our data. It has to be secure.

And most importantly, we have to keep our users happy.

So the elements of our solution are of course, with Meraki, is data security, management and support, application delivery and management, network infrastructure, and policy control, all of which fit really well into what Meraki has to offer.

So we are excited to be partnered with them and providing the solution.

This is Chase Dalton with Meraki. I have Scott Knight with me today. Scott Knight is my team lead SE out of the Atlanta area and is going to do a quick couple more slides just to give you guys an overview. But we are going to jump into the product today.

And what we are going to try to do is map back to those five bullets that Allen just highlight on.

How we can help you simplify policy; simplify policy around your users, applications, provide a higher level of security. And do all of this from a single pane of glass, ease of use, cloud managed network edge.

Scott, without any further a due, I’m going to pass it over to you.

Okay. Thanks Chase, I appreciate it.

For those of you that are not familiar with Meraki or maybe are just a little bit, here is a brief background.

Meraki is leader in cloud networking, so we have at least 20,000 customer networks. I believe that number is quite a bit higher at this point, that are actually out and deployed and up and running.

The background of where Meraki started is essentially that our founders were PhD students at MIT. They were working on a wireless mesh project as their PhD project. Simple network management; the idea was to be able to get this hardware out to the different locations on the Cambridge campus and have it deployed easily and managed easily.

They were presenting this out west and Google happened to be in the audience, expressed some interest, and lured them out of their PhD program to start Meraki.

So that’s where Meraki started and there was obviously some additional funds that came along the way.

And then most recently, in December of last year, the acquisition of Meraki by Cisco closed.

So what does that mean from a Meraki standpoint?

Basically, there is a new group within Cisco that has been formed: the Cisco cloud networking group. And the goal is to basically just continue to pour R&D into Meraki’s existing technology and grow that product set.

Obviously, with Cisco’s reach, we are able to get to even a much larger customer base than what we may have as Meraki by ourselves. So, it’s basically going to get us out there quite a bit more.

And then from a status quo, there are no plans to change our existing pricing and licensing models and we are continuing to grow the business here.

Meraki essentially has four product lines: wireless, switching, security appliances, as well as mobile device management. And we’ll dive into that a little bit here and then we’ll drill straight into the product so you can see it in action.

For those of you that are familiar with Gartner, prior to the acquisition, we were already placed in a very nice position on the Visionary Quadrant for wired and wireless networking. And then also in 2012, we were awarded the Technology of the Year award for cloud networking.

And a few others there from a recognition standpoint. Meraki was definitely on a huge upward trend.

Now from a cloud networking standpoint: cloud is kind of a word that gets thrown around all over the place here.

Essentially, what does cloud mean in the Meraki world?

I’m seeing a question here from Pembroke Pines asking if they are muted here. I don’t know if all the participants are currently muted right now. Was there a question, possibly?

Audience Member: What you have in the audience is a technical staff. We’ve done evaluations, you have a wireless engineer with Cisco certifications under his belt. So kind of what we want to hear is how a solution could potentially innovate our own bring your own device model for schools.

Our environment is a charter school site, a charter school system with six physical locations. Our deployment needs are around deploying Google Chrome books into classrooms. Kind of fit the classroom model where they put the kids will have mobile devices in the room.

We’ve looked at a sister site of ours, a local high school, St. Thomas Acquaintance here in Ft. Lauderdale. They did a 2300 deployment of Google Chrome and they used the traditional Cisco wireless environment and there were some costs. I think they did one access point per room deployment to address the bandwidth needs.

Kind of what we’re looking for is how this settles into the marketplace for us. We’ve done evaluations on the Cisco. We use Cisco wireless environments here in the city. We currently use a mixture of some Ruckus gear over in the schools and we’re trying to see how the Meraki could be a better fit to the Ruckus.

I know one of the limitations on the Ruckus for our future plan was AP and I was hoping that we could address those questions and the wireless engineer, James Gallow, asked very specific questions around how the interface ties back and there is a local survivable option on the wireless APs: if there is lack of connection to the internet.

Scott: We will go through, just to try to hit everyone here, we will hit the high level and in the product set itself, I think we will address a lot of those questions and at the end I think we will have some time set aside for specific Q&A.

So hopefully, if that’s alright, at the end we can bring up any of the points, specific questions. But that way we can try to cover the overview. And hopefully as we go through some of those questions will actually be answered as we go. Is that fair?

Audience Member: That’s fair.

Scott: Thank you for the question.

So, couple more slides here and then I’ll jump right into the product so we can kind of get some of those questions answered.

Essentially cloud from a Meraki standpoint, we see some advantages obviously from a manageability standpoint. So basically you’re logging in, you have a single pane of glass to be able manage whether it’s one site, ten sites, 100 sites, 1,000 sites. There is no limit there and you have that visibility to all of those sites.

From a scalability standpoint, essentially, like in the wireless world, you are just adding APs. So there is nothing that you are having to scale on your end from a management standpoint; I can essentially just add APs.

So if I have ten and I need to add fifty more, then I add fifty more.

And obviously from a cost saving standpoint, we don’t have a local controller requirement. Everything is being controlled from the cloud. So there is that piece from a capital standpoint, but also just from an ease of use and ease of deployment, your operational costs are going to go down quite a bit.

Now from a product line, I mentioned our four product lines; the MR series is our wireless, the MS switches which are access switches, and then the MX security appliance which is an edge device that has a gamete of features from site to site VPN, layer 7 firewall, content filtering. And we’ll get into that as we look through the demo.

And then our mobile device management piece, obviously helping from a standpoint of being able to manage the end device, whether it’s iOS devices, Android devices, Windows, or Mac devices.

So let me hop out of here real quick and we’ll hop into the demo.

So what I am going to show here is essentially the Meraki dashboard. So, I can go to an overall view of the network.

Basically, I’ve logged into this single pane of glass and I have visibility to my wireless, my security appliances, my switching, and my systems management piece. None of those components are dependent on each other, so you can deploy Meraki APs with other switches, you can deploy our security gateway and have different wireless.

However, obviously if you have all the Meraki components, you can manage it all from a single location.

I have visibility, obviously, from a Googlemaps view to see what’s out there. I have quite a few devices out in California in this view.

From there I can drill into our wireless for example. I can pull up our wireless network and in Meraki terms, a network is just a group of devices. So I have a group of APs in this scenario that represent our corporate wireless, as an example. I can upload custom floor plans.  I can pull up each one of those floor plans or just a straight Google maps view if I want. So I can pivot around that and see the network from different views.

If I want to drill into the individual floor plans that have been uploaded, I can pull those up. And then I have some options on here to be able to say, for example, I want to look at the number of clients that connected to each AP over the past week. Or maybe I want to look at the current clients that are connected to an access point. Or I want to see what the access point types are. Just a high level view of what is going on in the network.

Now I can drill into the access point and this is going to give me more visibility into what is happening on a particular AP.

So I have some high level information about what SSIDs I’m broadcasting. What’s my wired connection speed out of the back of the AP?

You’ll notice here that I’m showing what switch and which switch port I’m connected to. In our case, this is actually a Meraki switch, so it’s a hyperlink. So I can click on this and drill straight into the switch to start managing it.

If this was a non Meraki switch and I can still get the information on the port and what the switch name was, you just wouldn’t be able to click on it to go into it.

Now if I drill down here, I’ve got live tools on the AP itself. So I can see what the current Ethernet traffic load through the access point is and how many clients I have currently connected to the AP. And again, this is for this one specific access point.

I can see how long they have been connected, how much usage those users have had, what channel they’re on, what there signal strength is.

So this tends to lend itself to more of a troubleshooting view. So I want to see how crowded an AP is or, in this case, I’m pulling up channel utilization, and I can see on the 2.4GH frequency, it’s pretty crowded. My 5GH frequency is looking okay. So I have some real time troubleshooting tools to be able to see what’s happening on the AP and then I can do some basic pings and throughput tests and trace routes to just test network connectivity.

You’ll also notice that we have mesh neighbors listed and all of our APs will automatically mesh with each other wirelessly. So if you have a scenario where you have a place where you don’t have cabling and you need to get an AP, you can have that wirelessly mesh to a wired access point and it will become a repeater. Or if you lose Ethernet connectivity but you still have power, it would automatically leverage one of its neighbors for its backhaul.

And that kind of goes back to some of the original pieces of the original PhD project where they were working on that mesh capability.

Now that was looking at a single AP. If we go up a little bit and look at more of the network view, I can start to see all the clients that have connected to any AP on this entire network.

So I can see the clients listed. I can see them by name, so I can see what there host name is, whether it’s net bio name, bonjour name. Grabbing that information as traffic passes through so that we can give you more information than just a Mac address.

So if you’re troubleshooting and want to find a particular client, and I can literally just type in their name and narrow it down versus having to go find their Mac address or ask the user what their IP address is, for example.

You’ll also notice that we are doing some device and OS finger printing. So you can see operating systems. So, for example, if you want to pull up all of the Apple devices, I can pull up any device that falls into the Apple realm and that may be Macs, could be iPhones, could be iPads.

From there, I can drill into a particular client. And now I can see, number one, I can see an approximate location so based on who they are connected to and other APs that can see them. I can see an approximate location on the map. I can see their signal strength.

I can also see what their traffic levels look like as well as what type of traffic. So for example I can see that 180 mb/s for Dropbox – this particular client. So, quite a bit of information on what the user traffic patterns look like even down to individual destinations that I can pull if it’s a piece of traffic that’s not being categorized as a specific application.

Now I can go to my applications view and I can pull up all of the applications that are being run across these APs.

So I can pull up for example, Dropbox, and I want to see which clients are contributing to Dropbox on my wireless network as a whole, and then sort them based on who is using the most. I can see that this particular client has the most Dropbox usage.

Now I can go back to that client, and let’s say that they are just severely abusing the network and I just want them off the network entirely. I can edit this client and say that I want to block this user and put a message in and they are going to get a splash page now that says, “you have been blocked for XYZ reason.”

I can also apply group policies here. And what group policies are is basically a set of rules for that user. And it could be bandwidth limits, it could be VLAN access, it could be splash page behavior. But basically, it’s a group of rules that can be applied to a client and we can either apply it manually or we can apply it dynamically.

So, if you imagine, I can get user information, active directory group membership. So maybe I apply a certain group policy based on your AD group membership.

Or, since we know the operating system, I can also turn around and apply policies based on what device you have. So this really plays into the BYOD scenario where I want all of my iPads to drop into a particular VLAN or maybe I want all of my iPads to have a specific bandwidth limit or certain firewalls rules. And all that can be done dynamically. This is just an example of where that can be applied on a manual basis.

Now if you want to do more high level traffic shaping, from a configuration standpoint, I can drop in to per SSID firewall and traffic shaping.

So, for example, if I want to shape all video and music or maybe I want to shape specific gaming applications, I can pull those up and then I can simply set a limit for what that particular applications are. And this is all per SSID, so I can have different rules for a guest network than I do for an internal network. Or different rules for a student network versus a teacher network- things of that nature.

Now from an overall configuration standpoint, it’s very simple. From a deployment scenario, essentially, I either plug in my serial numbers or my order number and it will prepopulate the serial numbers into the dashboard. I can do all of my configuration without a device being plugged in and then once the device plugs in, it securely phones home to the Meraki cloud infrastructure, grabs its config, grabs the latest firmware, and it’s up and running.

So from an initial deployment standpoint, it’s very simple. And also from an adding or growing standpoint, it’s literally a matter of just adding APs.

You can see here that I have my different SSIDs set up. This is a nice page to give me a high level view of what my settings are for each of these SSIDs. And then I can drill into a particular SSID and start to configure that particular SSID.

Is it a pre-shared key? Am I using 802.1X, for example. So I could do 802.1X to a local radio server this kind of brings up the question that was asked: what happens from a survivability standpoint? So these are all cloud managed – what happens if I lose my internet connection?

And the answer is that there is a local config on the device so it’s going to continue to run, it’s going to continue to function. Existing connections aren’t going to be affected. New users can be authenticated as well, like in this case if you are doing authentication to a local radio server, you are going to be able to authenticate all day long as long as your local network is not down as well. And then once the internet connection comes back up, then any of this data that you can see would get cued up and get sent to the cloud as well.

Audience Member: That’s only 802.1X. What if we’re using pre-shared key?

Scott: With pre-shared key, you’re fine because all that information is kept on the device itself.

Audience Member: Would it store that information?

Scott: The access points would store that information. So, if my internet connection is down and I connect to an access point that is a pre-shared key, then I type in my pre-shared key and I’m off and running.

Obviously, I wouldn’t be able to access the internet as a user, but I would be able to access any local resources that were tied to that particular access point or that network.

The only time that you would introduce the cloud as an authentication mechanism is if you chose to use Meraki as the authentication. And honestly, this is typically going to be for those environments that just don’t have an AD infrastructure, they don’t have any radius and they want to actually leverage 802.1X without having to build out that infrastructure.

And in that case we can point them at the cloud for authentication, but if you do that, you are introducing dependency on the cloud. So our more common scenario is 802.1X to a local radio server or pre-shared key or open with a splash page kind of scenario.

Audience Member: Once again, when we’re using our own radio server for 802.1X, that information is stored on the local radio. So in the event that it needs to authenticate, it can hit the local radio servers still.

Scott: Yes. Absolutely. Yep.

Audience Member: Because I believe in our environment, we’ll have, obviously, guest access which will be 100% internet.

Scott: Yep.

Audience Member: And then if the cloud is down, then the internet will be down, so it’s pointless.

Scott: Correct.

Audience Member: However, we’ll also have AD clients that will be connecting to local resources which will be 100% necessary to connect to even if the cloud is down.

Scott: Yep. Absolutely. That is an extremely common scenario. And again, you’re not a affecting your local access by not having that cloud reachability. Everything will continue to function there.

So without going through all the bells and whistles here, I did mention being able to assign group policies based on a device type. So you can see here that I have a list of device types. And I can choose, you know, Androids to get a certain group policy and that way once a device is on the network and it’s identified as an Android device, then it will automatically be assigned that group policy which could then apply certain bandwidth restrictions.

Now another piece that is interesting from a Meraki standpoint is being able to use what we call NAT mode. This is for assigning IPs to clients.

Most typically used in a guest environment and this is where the AP itself will hand out an IP address to the user. And the user is NATed at the access point and so using this in conjunction with a single fire wall rule that says “deny access to the local LAN”, I can basically create a walled garden for users.

So I’m not having to use up my IP space for them. They can’t get to my local resources. All they can do is get to the internet. It’s a one way outbound NAT. But it makes it extremely easy to set up. They can’t see each other. So it’s basically a quick way to isolate users. You could go the other direction and drop guest users into one VLAN and internal users into another and then control their access upstream. But this just makes for a pretty easy scenario for that.

You can also see that we have a Bonjour Gateway functionality integrated into the AP. So this is if you’re getting into access into Apple TVs or Apple printers across different VLANs. Since Bonjour is contained to a single subnet, then we have the ability to forward that traffic to other services within the AP itself.

And lastly, I wanted to hit on SSID availability. I’ll hop into some of the other products here as well.

SSID availability is where you can actually set up a schedule of SSIDs. So, for example, if you have a guest network, and you want it to only be on during business hours or during school hours so you don’t have people hanging out in the parking lot hopping on the wireless. You can set up a schedule and then it will automatically turn on and off the SSID during that scheduled time.

Now you can see here that I’m in the wireless, but let’s say I want to drop over and start looking at the switches, for example. Same dashboard, same pane of glass. I can hop right into the switching view.

Again, just to review, our switches are access switches. Right now they are layer two only switches and we have 24 and 48 port, non-POE and POE options.

The unique part about Meraki switches is that you’re rolling that up to a single view from a management standpoint. So I can drill into an individual switch if I need troubleshooting; very similar to what we saw in the AP side.

So I want to drill into a switch and see what ports are active. You can see that this lightning bolt is indicating that POE is active on that port. I can see my overall POE consumption on the switch versus what was budgeted. Or I can drill into an individual port and see how much POE is being used on that particular port. What clients are connected, if there is a LLDP enabled device. For example, this is a phone. I can actually see that phone from there.

If I go back to my switching view… again this is just a view of the switches themselves. But if I want to actually configure a switchboard, we have the concept of virtual stacking.

So essentially all of the ports on these switches roll up to this view. So if I need to find, for example, all of my switches on the third floor, I can just type in “third” and maybe I want my POE switches and maybe I want ports 1 through 5.

So I can find my third floor switches that have POE enabled and I only want to see ports 1 through 5 on these switches. I can easily pull that up.

In this case, I am pulling up switches that are the same floor. Those could be in different cities, different countries, different closets, however you want to carve it up.

But essentially instead of managing switches, you are managing just ports. So I can pull up all of these ports if I wanted to edit them at the same time and set them to an access port, I could set them to a trunk port. For example, I want to do a trunk port and maybe I set a native VLAN.

All of this can be done and then update the ports and it doesn’t matter if they’re on the same switch or on the same location, it’s going to get pushed to all of those individual switches.

We have pretty interesting capabilities with Tags. So I can tag a port based on, let’s say I want to find all of my printer ports.

Audience Member: Just so we can stay on course, let’s really focus on the wireless capability. That’s kind of our current concern. We’re fast track so we may sound a little anxious in driving the conversation towards getting a better understanding around the Meraki wireless capabilities… so if we can kind of go back down that path. That’s where we want to focus.

Scott: I wonder, Chase help me out here. I know we have a lot of folks on this call. Do we want to schedule a follow up specific to the wireless with the folks that want to dive deeper on this? Because I don’t want to cut short the other pieces either.

Chase: No I agree, I think for today and just for the sake of time, we only have 25 minutes left, let’s continue down the path so we can cover the MX. I think the next gen firewall is really important to cover here and obviously MDM because that completes the BYOD story. We can coordinate some time probably with Allen to coordinate that with the team that has additional questions and even if it is a follow up immediately after this. But I think that we need to stick to the agenda that we have today. Thank you.

Scott: Okay, thanks. So certainly, we will get the additional questions answered here. I appreciate the cooperation on that.

Now if I’m looking from a switching standpoint, I want to tag specific ports and I want to pull up all of my printer ports, for example, I can then search for those tags. And again, I’m going to find all of my printer ports across whatever switches that I have. So being able to pivot around that data and find those ports quickly and easily no matter where they are is pretty powerful.

On the same token, I have the same kind of client view that you saw on the wireless side on the switching side. So I can pull up the operating systems, I can see the manufacturers, I can see the Layer 7 capability, which again, is a fairly unique attribute on the switching side.

And from a troubleshooting standpoint, I can easily find clients in this particular view by a quick search.

Say that I want to find a particular device, I can pull that device up, and now I see the device, the IP address, the MAC address, which switch they are connected to, which port they are hanging off of, and their usage.

If I’m trying to track down a particular MAC address for example, I can do it in one search versus starting at my core and working down a trunk link and trying to find a user that way.

There are some unique troubleshooting capabilities… I actually didn’t touch on this in the wireless. This does exist on the wireless product line as well. And that’s the ability to do a remote packet capture so I can pull a particular port.

I could say I either want to view the output in this screen or I want to download to a .pcap file and open it up in Wireshark. But essentially this is allowing me to run a capture remotely and pull detailed information from a particular switch port. Or in the case of wireless, from the wired or wireless side of the AP.

Now, for the sake of time, I am going to hop over here to the MX. And I apologize, I know that we are kind of running through this quick, but we want to leave some time for some Q&A at the end as well.

So the MX is our security appliance and this is everything from a desktop size branch office type MX all the way up to a datacenter sized MX for VPN concentration for hundreds or thousands of sites.

The MX has quite a bit of feature functionality built into it from a Layer 7 visibility standpoint. So I have, as you saw in all of the other products, visibility into all of the applications that are traversing this device. And then the ability to do traffic shaping and Layer 7 firewalling at the edge.

I can pull up a simple firewall rule base that all of you are well accustomed to; IP and port based firewalls. I can do Layer 7 firewalls. If I want to deny specific type of applications, for example, I can deny those. And then I have standard port forwarding rules and one to one NAT rules that you would expect on a firewall.

I also have the ability to do content filtering on this device. So we partner with BrightCloud for our content filtering database. And this is where you are going to get into more information on specific categories of URLs and those categories are maintained by BrightCloud and we leverage those. You could do that on a per appliance basis or you could actually tie that in to active directory.

If you want to be able to tie specific AD groups to different content filtering categories, you can basically tie it to your AD server, grab the group information, and then set the policies based on those groups.

I see that I have a policy for contractors. Maybe I want to set up one for the users group and then I can choose different categories for that particular group. And that way I may have different restrictions for different groups of people that I want to be able to handle.

We also have site to site VPN. And this is probably one of the most powerful features of the device and that is basically a couple of clicks to have a site to site VPN.

So I can set up, with basically a click here, do I want to set up a split tunnel or full tunnel? Which of my internal subnets do I want to advertise across this VPN? Simple yes or no. Then once I click OK, any other device that is in this VPN would now have access to those internal subnets.

The nice thing about us being cloud managed is essentially we know what the public IP address of that remote site. So if that changes, then we can update the peers to say that the IP address changed, you need to reestablish your VPN out to that remote.

So in a lot of cases it allows for a lower cost circuit because you are not paying for the static IP address that you may need in some of the other traditional VPN scenarios.

Across that VPN, we can also enable WAN optimization. This is TCB compression. It’s deduplication of H2TP of Windows file shares, ftp, some of the heavier protocols we are going to try to optimize across that VPN. And all of that is kind of rolled into the solution there.

You could drop multiple internet connections into the device. So if I want to lead balance across, let’s say, a DSL and a cable connection, I can drop both of those two into an MX and load share or just have a primary backup scenario. And then I can also plug in a 3G or 4G card into a USB port as a backup or even as a primary.

Or a lot of our customers leverage that to be able to turn up sites quickly. So if you have a lot of remote sites, you want to be able to send out an MX with a USB card, plug it in while they wait for the traditional circuit to land. Once the traditional circuit lands, drop it into the MX and send the USB card to the next one.

So it makes deployment extremely quick and extremely easy from that standpoint.

We also have antivirus scanning and IDS capabilities on the MX as well that can be enabled. And then, essentially you can pull in your white list of signatures that you don’t want to report on from an IDS standpoint and things like that.

And then we will also, I believe in the next few weeks, we’ll have some announcements around some more education focused features that are going to be coming down the pipe as well which will be even more from a feature standpoint on this. So this is going to sit at the edge of your network as a firewall security appliance.

Now, lastly if I drop into our fourth pillar, our last product line that we talked about. Meraki Systems Manager is a mobile device manager. It’s actually a device management because it can actually manage Windows and Macs as well. And this is actually managing the end device.

This is the ability to, let’s take iPads for example, or iOS devices, the ability to pull up for example, let’s say I want to pull up this iPad and let’s find one that was connected recently. I can pull that up. And I’m going to have visibility into the device itself.

We can see what’s the battery charge? What’s my warranty look like? What applications do I have installed on the device? I can send notifications. I can lock the device, erase the device.

So having extreme visibility into the device. And then also to be able to lock it down. If I want to set some restrictions: they can’t use the camera, they can’t install their own apps. I can lock all of those restrictions down on the iPads themselves and then push those out to the devices.

And I can do this with different profiles, so for example, let’s take a school scenario. I have school loaned iPads and I have students and I have teachers. And I have different restrictions that I have for those. I just simply tag the device as student or teacher and then I can apply those profiles based on that tag.

I can also set up wireless profiles. Let’s take the example of a pre-shared key. If I want to push out my wireless profile to all of the users without them seeing it, then I can either manually set that up or if I have Meraki wireless, I simply choose my wireless network from a drop down list, I pick the SSID and then I push that information out to those devices.

And then lastly, I have the ability to push applications. Centrally I can go to the app store. I can search for an app for example. Let’s take Evernote for example. I can find that app, add it to my dashboard, install it either on all of my devices or only devices with a certain tag.

So again, with our example of student/teacher. If I have a student app that I want to push out, maybe I only install it on student devices. And then that’s going to push that out centrally.

We can tie in with the volume purchase plan as well. If you have redemption codes from Apple, then you can manage those from Systems Manager and be able to keep track of where those codes have been used on those devices.

And the kicker with mobile device management with Systems Manager is this is all free. So you can go out and sign up for Systems Manager after this call and play around with it, get your own dashboard account and leverage the capabilities for free. And there is no limits on devices. I actually had a customer last week that are managing about 1200 iPads in their school system and are loving it.

I know we’ve got about 15 minutes left here and I know that I have kind of breezed through this. I guess, lastly here, the same piece for iOS we do have for Android so you can tie into the Android marketplace; be able to push those out.

And then from a device restrictions standpoint, you are going to notice that from an Android standpoint, there are a little less restrictions available currently.

I can do a lot of my Wi-Fi settings. I can turn on and off the camera. And we are actually working with individual device manufacturers to add additional restrictions because Android’s API is somewhat generic.

So to be able to get the level of granularity that you see on the iOS side, we are having to go the Samsungs and the HTCs and get access to their APIs to be able to build that in.

And that is all in process. So you’ll see some more of that coming out here soon.

So I guess with that. Chase, I will hand it back to you and see if we have Q&A and kind of wrap up from here.

Chase: That would be great if we could just go back to the slide deck. I thought we would use this opportunity to talk a little bit, except for the questions that have come up. I do have a slide or two just as some action items for those on the phone.

So one of the things we wanted to reward you guys for joining Meraki and Adcap for this presentation and actually give away a Meraki access point with a year license to someone on the line. One of the things to do with that, I’m going to have Samantha Couzens, who is with me – she is the Marketing Manager at Adcap. She has the list of attendees who actually joined today, not just those that registered. And I’m just going to let her draw a name. If she wants to introduce herself real quick and Meraki will be happy to follow up with you after this through Samantha to make sure she gets your shipping address to send you the Meraki 12 access point. Samantha?

Samantha Couzens: Hi guys. Okay, so I’ve drawn a name and I’m not going to butcher the pronunciation. But the winner of the access point in Yuni Infante from NeuroCall.

Chase: We’ll follow up with you after the call. I appreciate you guys being on that. If you do have interest in trying out Meraki hardware or possibly another webinar. We do qualify attendees for access points on the ones that we do two to three times a week at Meraki.com.

You could also try gear anytime if you have questions out of this. If you saw something that was interesting that you want to take back to your lab. Maybe you want to see the MX firewall or the MR access point.

If you follow this link that is on the page or write it down you need the trial and you need the reference code at the end there. Meraki.com/form/trial?ref=107cm6l. We will actually qualify you there as well for free trials for any of the gear and actually get you to work with the appropriate Adcap AM in your area.

Thank you for joining us today. We do have a few minutes left. If there are any questions, I’m happy to get around to talk to those one on one. Otherwise we appreciate you joining and we hope you all have a great day.

The NexentaStor HA Cluster plugin can be a bit of work to set up (see previous post), but it is definitely worth the effort. I had the good fortune to go through some validation testing with some talented Nexenta engineers using the system that I set up in the Adcap lab, so I got to learn the ins and outs of the High Availability setup. The clustered high availability demo system is circled in green in the picture below.

Adcap Network Systems Test and Development Lab

The controllers are Cisco C240 servers (on loan from Intel) and the JBOD’s are from DataOn Storage. I discussed the build and initial setup in my previous post Nexenta High Availability ZFS Storage Systems Using Cisco and DataOn. The Cisco UCS B series blade server system is circled in blue, and the Cisco Nexus 5548, 5596, and 2000 are circled in orange – they are used in the IOMeter testing of failover.

I made some improvements since the first build of the system. The 10GbE NIC’s are Intel X520′s and are operating at full speed with jumbo frames, all the hard drive bays are filled, and the sTec SSD’s and ZeusRAM are in full use.

This is one configuration of the Adcap SwiftStor product. The validation testing involved stress tests, equipment tests, and failover tests for any number of different hardware and software faults. After the validation was done, I rebuilt the cluster then took a few videos and screenshots demonstrating failover of CIFS, NFS, and iSCSI.

I’m going to skip over all the basic setup. This was covered in a previous post on Cisco Nexenta ZFS Storage System Configuration and Benchmarking.

The HA Cluster shares volumes between two controllers, but the volumes have to be created first. I found it easiest to create the volumes all on one of the controllers first, then share them out from there. If the cluster is removed, the volumes revert back to the controller on which they were active at the time, and are exported. You would just have to go to Import Volume to get them back up and running with no loss of data.

I set up two volumes. One with twenty 3 TB drives, set up into four RAIDZ1 groups, called Large_Volumes. The other a set of ten Mirrors, with two 400GB SSD’s for L2ARC (read cache)  and two 8GB ZeusRAM SSD’s for Synchronous Log cache.

Next we establish the cluster. Even through it can all be done with the GUI, I had better success establishing the cluster using the command line. The command line provides a few more helpful hints and seems to have a better flow.  I found that when I used the GUI I would go back and forth between the two controllers, which causes issues. I recommend using the command line to create the cluster, if only because it forces you to set up everything from one controller.

As shown below, the Mirrors are shared out on a Virtual IP address (VIP) of 10.124.12.204, and is currently managed by the C240-HA-A controller. The Large_Volumes are shared on VIP 10.124.12.214, and currently managed by the C240-HA-B controller. Heartbeats are done on both the network and the hard drive side.

This is an Active-Active configuration where some of the volumes are shared out by one controller, and some by the other. This permits full use of the processors, memory, SAS channels, and network of both controllers, while providing High Availability in case of a hardware or software issue.

After creating the volumes and sharing them out using the HA Cluster feature, and using different IP addresses for each volume, everything else that is created is done as part of the HA system, which means the configuration changes made on one controller are also updated on the other.

Each volume is then shared out using both CIFS and NFS. A CIFS password was set, and NFS version changed to version 3 instead of the default of 4. In an enterprise setup, the CIFS would be tied into Active Directory, and permissions set up properly on both CIFS and NFS. For the demo setup, I left if wide open.

By clicking on the individual volumes, the mount point for the CIFS and NFS shared are shown. CIFS is easy to mount from a Windows and Mac client. NFS is a pain in the butt with Windows and Mac, and I did not feel like messing around with it too much, so I set up an Ubuntu  Linux Virtual Machine to test NFS.

Accessing the CIFS from Windows was easiest by just typing in the IP address in the Windows preferred \\10.124.12.204\ format, entering the username of SMB and the password typed in earlier. Both the shares were available on both the IP addresses, as shown below.

So, on to the failover testing. This is a video that shows the failover of the cluster and how CIFS stays up and running during the transition of the volume from one controller to the other. During the video I use the manual failover feature of the Nexenta HA control. This has the same effect as if a heartbeat detection of a failure causes a transition of control.

There is a finite amount of time for the transfer, as can be seen by the network pings in the video. The Windows machines maintains the mapping and access to the shares during the transition, but the in-progress file transfer has to be restarted.

So, I did the same thing with a linux box using NFS for a file transfer. The problem was, I set the Linux box up on the Cisco UCS, and connected it to the storage network at 10Gbps. No matter how big of a file I transferred, it would take less than 10 seconds. At some point maybe I can find a 30GB file and transfer that, or set up Linux laptop and transfer over wireless so it slows things down. Until then, take my word for it that NFS is resilient.

For a more practical demonstration of the resilience of NFS, I set up three IOMeter virtual test servers on the Cisco UCS. I set up their storage as 200GB virtual hard drives using the NFS share on the Nexenta HA cluster. Then I ran a 120 second performance test, and failed the volume over from one controller to the other in the middle of the test.

This is a picture of the results. Obviously the IOPS in the graph are an average, because there was no storage activity while the VIP was unreachable. It is nice to see that things come back up instead of the Virtual Machine puking out.

This is a video demonstrating how NFS shares stay up during the failover. It shows the Nexenta HA interface, the IOMeter interface, and a continuous ping during the testing.

Then I did the same thing with iSCSI. This was a little trickier, because when I did the scan of the iSCSI from the VMware server, it found both iSCSI targets on the Nexenta box, and the iSCSI target for the Mirros was found on the IP address for the Large Volumes, which is not what I wanted. I found that the solution for this is to set up specific mapping of the iSCSI targets to volumes on the Nexenta box.

I had first set up a LUN, or ZVol as it is known, for the Performance Mirrors

The iSCSI targets had been created when the Virtual IP addresses were created during the Cluster setup, so they were already there.

The Cluster setup had also created Target Portal Groups, providing a way to separate out the volumes and IP addresses within the iSCSI realm.

However, it was necessary for me to create a Target group that put the iSCSI target into a specific group.

At that point I could map a specific LUN to a specific iSCSI initiator.

After this, when I rescanned the iSCSI targets from the VMware virtual machine, the correct iSCSI name was matched to the correct LUN and IP address. Even though this seems a little bit complex, this system is necessary when there are multiple LUN’s, initiators, and targets.

I set up three new IOMeter virtual machines with their storage defined on the LUN’s through the iSCSI connection. Then I did the same exact test that I had done with NFS using the iSCSI connection.

This is a picture of the results. Just like on NFS, it shows that there is a loss of connectivity in the middle of the test, and then it recovers.

This is a video. It is a little longer, because I also show a little bit of the iSCSI setup on the VMware setup.

This is a really solid implementation of High Availability Clustering. The setup of the system is straightforward, the tools to use it are powerful, and the failover works well. By having each controller be the primary manager for a set of volumes a true Active-Active configuration is enabled. Both controllers are able to use the capabilities of the processors, memory, SAS controllers, and network connections to full effect.

_________________

Updated 5/12/13

I have four more failover videos for those of you who would like to see the actual time it takes to failover in real world cases where equipment fails or is disconnected.

In the first video I use the Cisco Integrated Management Controller to do a hard reset of the active controller.

The power cycle is done while running a continuous ping, monitoring the Nexenta High Availability Management GUI, and running both and iSCSI and NFS test using IOMeter.

In the second video I go to the test lab and pull one of the SAS cables from the active controller. The backup controller for the volume figures out that there is a problem and takes control of the cluster. The previously active controller does a controlled reboot.

The SAS cable pull is done while running a continuous ping, monitoring the Nexenta High Availability Management GUI, and running both and iSCSI and NFS test using IOMeter.

In the third video I pull first one then the other of the 10GbE network cables from the active controller. One of the cables is jammed in tight, so I have a hard time pulling it out. But after I do, the backup controller for the volume figures out that there is a problem and takes control of the cluster. The previously active controller just hangs out until the network is restored.

The network cable pull is done while running a continuous ping, monitoring the Nexenta High Availability Management GUI, and running both and iSCSI and NFS test using IOMeter.

In the fourth video I pull both of the power cables from the active controller. The backup controller for the volume figures out that there is a problem and takes control of the cluster. The previously active controller does a controlled reboot.

The power cable pull is done while running a continuous ping, monitoring the Nexenta High Availability Management GUI, and running both and iSCSI and NFS test using IOMeter. Unfortunately I was a little fast on pulling the power so the results just show what happens after failover.

Posted at: Adcap Network Systems Blog - Adcap is the best source for purchasing and support of the Cisco Nexenta ZFS Storage System.

Adcap SwiftStor is a fully supported Open Storage system. Check it out!

Author: Rolf Versluis

Twitter: @adcapnet
LinkedIn: Rolf Versluis LinkedIn
Facebook: Adcap Network Systems Facebook Page