(SolidFire theme)
- [Narrator] Hello, this is Ed Balduf of SolidFire.
Today I'm going to take you through some examples and demos
of how to use the SolidFire puppet providers
to manage accounts, volumes, and volume access groups
on the SolidFire cluster.
So let's begin, you can see I've got four windows here,
the top two windows are logged into my puppet server
and the bottom two windows are logged into
two different clients so we're going to kind of show you
how to do this in two different ways here.
So let's start by looking at our manifests
that we're gonna use.
Basically we're gonna use, make this window a little bigger.
We're gonna use the generic site.pp manifest
and I'll walk you through what we've got going on here.
So the first stanza here is actually the second thing
we're gonna work on, which is where we define
the node to be the name of the SolidFire cluster.
We're going to use the puppet device constructs
to take advantage of this.
But you can see I've gotten here defined
for the node SolidFire.balduf.localdomain
and account and volume you can see
I've titled the second account the puppet device here
so that we know this is coming from the device construct
and then we've named the volume dev-volume
so we know that also is coming from the device construct.
If we move down here a little bit,
we can see that I've defined a couple of variables.
The URL is something you'll see me use a couple times here
and this is basically a compound URL
with a cluster admin account and password
and then the domain name, or it could be IP address
of the SolidFire cluster.
And then you'll see we'll use the SolidFire storage
virtual IP address here also.
And so this is defining a node that is our client.
You can see that's actually down here.
Should come up and say client, yes it does, okay.
And so as we walk down through this you can see
I define a bunch of things here, some of these things
we'll use in various different spots.
For instance, volume names, volume access groups
can't have dots so we'll replace them with dashes.
And then what we're gonna do is we're gonna go down
through and we'll define an account,
so we're gonna go create an account
on the SolidFire cluster.
Then you can see here we are defining a volume
on the SolidFire cluster.
And we'll continue down here,
we set up a volume access group, which we will include
our actual initiator which we defined up above here.
That's the initiator for our client.
We will use the volume which we created above,
so you can see SolidFire volume is called that down here.
And then we're gonna start execcing some commands
on our client to show some real usage for this.
So we're gonna go through and exec the iscsi_discovery,
we'll create a mount point,
then we'll put a physical volume or a PD group on here,
make a volume group on that volume that we're creating.
We'll create a logical volume here
and then we'll go down, we'll make a file system.
And we will, so here's the miking,
the file system ext4 and then we will make a,
we will actually mount the volume up.
So this example shows how you could set up,
and I'm going back up here in this.
How you could set up a manifest for a certain client.
One of the servers in your network somewhere
that needed to have storage for a database
where hypothetically setting this up
or mounting it to something called database.
And then the rest of your puppet manifest
for this node could configure all the rest
of the database goodness.
So let's go over here and we'll start our
master server, we're gonna start it in verbose mode
and we're not gonna put it in the background
so we can see the outputs that are coming out of it.
We'll go down here to our client
and what we're gonna do is, I mean,
if all works well, this should be not very entertaining.
But that's why we do these things,
to make this all automagic.
So we're gonna run puppet agent,
we'll run it in the test mode so it'll just apply it now,
not go into the background and do it later.
You can see our server jumped up
and said it was doing some things
so it's processing the manifest
and sending that processed manifest over to the client.
The client's going down through here,
spitting out some messages,
telling us it's ensuring things are created.
You can see those at the bottom.
At this point in time, it's mounted the volume
and it's creating the file system,
which takes a little bit of time here.
And there we have it, we're done.
So you can see it's said all kinds of good things.
Well, let's go see what we actually did.
So if we go and do a DF, we can see that we actually have
our database group logical volume mounted on mount database.
But let's look into a little bit more of this.
If we do this,
you can see that there is our iscsi connection
to the SolidFire.
We've named things so again, if we go over here
to our manifest, we can see, I named things,
SolidFire account name here was actually
the fully qualified domain name of this client
and that account name winds up right here
in the string for the IQN.
So we can also go look at the SolidFire itself.
So you can see beforehand that we had nothing there,
when we refresh the volume screen, you can see that we have
a volume called client-localdomain-sdb.
And we can actually see the account over here,
so once we refresh this and we get the account name,
then we go back over here to volumes.
We should actually get the account name to come up here
in the volumes screen.
Also you see we've created a volume access group
so we can go look at those in detail.
It also has client, the local domain.
If we edit that, we can see it's got the volume in here
and here's the actual IQN that we had up over here.
It did everything we expected it to do
and mounted up our volume.
So that's again, that's not very exciting,
there's not a lot that happens there unless it was a demo
and Murphy were to show up.
So let's go and look at the puppet device concept.
So the puppet device concept is such that
basically you have a different client,
it's called puppet device, and it's a proxy
for the network device.
And so it allows us to go back to the server,
so when we run it over here we'll go over the server,
it will gather the information up and pull that back.
So one of the things you'll notice up here
is that in this manifest, we had to put a URL.
We put this URL that I defined up there in every resource
that we define in here.
When we look at the manifest for the actual network node,
you'll notice there's no login information.
That actually comes from a file on this client
so if we do a more of,
you can see there is a device file here.
And this device file gives us that URL.
So it has that URL all in that device file and it's there.
The challenge with this is that it's a separate client.
It's going off and it's creating these volumes and accounts
on the SolidFire but it has no relevance
to this other client, so it could create that volume
and the account and make it into the volume access group,
but then we need a synchronization mechanism
to go over to this client and have him mounted up.
So that's why we find the, the first thing I showed you here
a little more, the puppet agent and the puppet agent
talking to the SolidFire, a little more useful.
But that has the drawback of every puppet agent
is going off to the SolidFire, and so if we have too many
of those we may overwhelm the API capabilities in SolidFire.
So having a single puppet device would push all those
API calls to a single host, which would make it
a little more manageable.
Also could be some security issues in there too.
So let's see how this works.
We basically use the puppet command
with the subcommand device.
We point it at our puppet server and so it too will go over.
You'll see that the server over here on the left
is doing some things, it's compiled a catalogue,
we've got some warning over there
about a qualified domain name, but that's not really
what we're looking for.
What we wanna see is if these two things here
have been created and so the magic has happened
and there it is, we have an account called puppet device
and we actually have a volume called puppet device.
So couple other things you'll notice here in the manifest,
on both of these manifests, we've put in IOPS,
so we're putting in the IOPS for that volume.
You can see those come over here to the SolidFire
managed accordingly as it should be.
And so one of the things we can do now
is we can modify this manifest
and make this, I don't know, we'll just make these something
so that we can tell they're different.
And we'll write that off and now we'll apply this again.
So again we'll see some stuff
come out of our puppet master here, this has happened.
Of course we need to refresh this screen so we will do that.
And you can see here that we've done our changes
to the quality of service as requested
by changing the manifest.
So again, that's changing the manifest on the puppet server.
One last thing.
You can see we ran this twice
and it did what it was supposed to
and now if we want to remove that volume,
we can change this to ensure that it's absent.
We can run this again
and again it'll go off and do its thing.
It doesn't show much.
But if we go back to our volumes and we refresh it here,
you'll see that it's gone.
So we obey the present in the absent commands
in the manifest.
So hopefully that was a good demonstration
of what the newly released puppet modules
for SolidFire can do, and with that, I will wrap up.
(SolidFire theme)