JIM THOMPSON: Hey, guys, maybe a little history of Avere.
We've been around for seven years.
I've been with the company six years.
And we've actually developed a caching technology
to accelerate network-attached storage.
If you've seen any movies in the last four or five years,
and some of the customers are here,
we've had something to do it.
We've been accelerated the NAS access
from the render nodes, or transcode engines,
or even the artists.
So We've had a bare metal machine for a long time.
And just recently, over the last eight months,
we've developed a virtual machine.
And we're pretty excited to have Google part of that now.
And over the last year as well, we've
developed a connector into any type of object storage device.
So we're using S3 API to connect in to any type
of either Cleversafe, Apple data,
or any software-defined storage.
So we're pretty excited to have Google part of that today.
So the two offers we have a Google--
and again, we're not new to virtual machines at all.
We've actually been using virtual machines
for a number of years.
Our QA engineering team use our own virtual machines,
running VMware as a matter of fact, to do any engineering QA.
It keeps the cost down for billing out hardware
to do that.
This Google offering's pretty cool
because the storage that you can use
is just infinitely expandable.
And the compute engines that you would use for rendering,
you can expand that out to whatever you want.
So what we do is we offer up a file system--
We're a proxy to a file system, either from an object storage
device or some other type of NAS, type of device.
So we offer up [? NFS assists ?] to the clients,
and it could be artists, it can be rendered nodes,
it could be transcode engines.
And then, in turn, we talk NFS and the S3 API
back to the storage device.
So the target industries are media and entertainment,
life sciences, and financial services.
Like I said, we've been around for a long time.
We have hundreds of customers out there.
The early adopters were media and entertainment,
so I think that's why this is going to be pretty interesting,
this offering from Google.
So what I'm going to do, I'm going
to talk about configuration here.
And if there's any questions, if I don't cover something,
please ask me later on.
Initially, like I said, we had a bare metal appliance.
The bare metal appliance was installed On-Prem, of course.
And the reason for that is to offload
that NAS product, whatever type of those legacy NAS vendors
you have.
From the IOPS that these render nodes were beating the living
you know what out of the storage.
So we're offloading all that stuff.
What I mean is that we're putting the active data set
into our tier.
We're a caching appliance.
We're a proxy of the file system.
We have multiple different mediums inside of our devices.
We have DRAM for fast access.
We have NVRAM for writes.
We have SSDs and SAS drives.
So we move data back and forth between these different
mediums, depending on the active data set
and what the needs are from the render nodes
and whatever other clients.
So on the bottom half of this slide,
you have the On-Prem storage, you
have your render farm, as well as your artists.
And on the right of that, you have the NAS and object store
device.
Not necessarily say that you would have an object storage
device, but that's something we think
will be pretty impressive going forward because the NAS vendors
cost is getting over the top.
On the top, we have the Google Compute Engine.
So we talked about burst computing a little earlier on,
and if you don't have enough hardware On-Prem in order
to finish the jobs that you have,
it'd be great to be able to spin something up
into the Google compute.
In addition to that, you can use Google Storage as well.
But the thing is that in order to do something-- in order
to really utilize the compute farm and Google,
you have to be able to get the data up there.
So what our devices again-- remember,
I mentioned it's a proxy.
Well, what that means is if a request comes
in, either the bare metal machine or the virtual image,
and we don't have it, it's a cold cache.
We're going to go back and get it from the storage.
So on the bottom, if that was a bare metal machine,
if the render nodes make a request for something--
say it's a new job, a new render,
a couple shots of your rendering--
we're going to go back to the NAS product,
grab it, and stick it in there.
And we're going to keep it there forever
until there's competition for space
because obviously the job's going to finish,
and something else is going to be more important.
The same thing happens for the virtual machine.
On the top left, we have the Google Compute,
and what we've done is we've utilized their software
to the build a virtual machine cluster.
We're a clustering solution of high availability.
So you could build this cluster out of the 50--
I don't have a customer that has 50 a cluster.
I think the largest cluster I've seen is about 21,
but that's not usually normal.
But in any event, you can scale this cluster
within Google Compute, depending on how many
IOPS you're trying to drive with your particular job.
That virtual cluster can also access the On-Prem storage.
So again, you don't to copy data up into the cloud
and leave it there.
You can just fire off your job.
We're going to go back to the On-Prem storage
to grab that data, and shove it into our cache,
and keep it there.
We're going to replicate that data
amongst all those virtual nodes and serve it,
paralyzing it out to the render farm.
So when you're done with that, when you're done with the job
and need to output that, you could write it back
to the Google Cloud storage, or you could write that
back the way down the On-Prem.
We offer our global namespace that I'm
going to talk about in the next slide that kind of goes over
how we can put this all together in one big globe, so to speak.
So since we're a proxy of the file systems,
we take either the NFS exports or those buckets,
from either Google Cloud Storage or your On-Prem object store
device, and we roll that into a file system.
We're going to present that, even an object storage device--
we're going to present that as NFS or SMB.
In addition to that, what we can do
is we can roll together a namespace around all
these different NAS products or object storage devices, as well
the Google Cloud Storage.
And what I mean is that you could potentially just mount
slash at the top of the hierarchy and just cd
and change the different directories or shares that we
would have representing these different object
stores, the buckets, or also the On-Prem storage.
What's really interesting is that global namespace
is fun and everything, but I think
what's really compelling is if you could do something
really interesting with it, like move data behind the scenes.
And the reason why we can do that
is because we terminate the protocols,
but we also offer up own file system IDs.
Again we have to do that for object storage devices anyways
because there's no such thing as file system ID.
Just a common object storage device, what we do
is, these buckets that are being presented to us
we gather into our namespace, we look at those objects
as actually blocks.
So depending on what object storage device it
is-- it could be a 1 meg, it could be 4 meg,
actually, block size-- since we treat object storage
device a little differently, we actually cache
the data differently than we do in NAS product.
We try to keep all the metadata for all those buckets
that are active and even keep the first 16 KF files.
We also offer now, that just came out a couple months ago,
is we offer up a snapshot for your object storage device.
So if you had either an On-Prem of your cluster
that you already have, and you're accessing the Google
Cloud Storage, or you have your cluster within Google Compute,
we could offer snapshots for that.
So you could have versioning for that particular data
that you're dumping out there.
Since we offer up our FSIDs, that
allows us to do some gymnastics behind the scenes.
What I mean by that is it you're able to do
a move or mirror of data.
And in this example, what we're doing is
we're actually moving from your On-Prem storage,
whether it's object storage or some type of legacy NAS
product, up into Google Cloud Storage.
So we can do that without anybody really knowing.
In other words, what I mean is that the clients
won't know any different that something
has moved because we're offering up the FSIDs.
So the FSIDs never change.
So your clients are never going to see any type of stale NFS
handle or anything like that.
Here's an example of, we've seen this slide
a little bit earlier-- This is an example of actually
one of our customers, and there's two,
there's the one in media entertainment
and there's another customer that's
not in media entertainment.
What they have is multiple locations
that are accessing either the Google Cloud
Engine for a rendering, or some kind of compute of any kind,
or also accessing the On-Prem storage.
And what's not shown here is that one
of the things that we do is we eliminate the latency
that your clients are seeing when they access that NAS
storage or that object storage device.
So since we eliminate the latency--
we're a latency killer as well as an offload engine--
we can place these bare metal machines
at some other location.
So in this instance, there's people here in the crowd here
that are using it for remote WAN caching.
So you could have LA, Vancouver, New York,
and any other location that could have these bare metal
machines caching, either for something that's
stored in the Google Cloud Storage
or actually caching for your On-Prem storage that would
be at a different location.
So most of the initial customers bought the bare metal machine
for just On-Prem acceleration.
And ever since then, after we came out
with the feature of WAN caching, they're
actually putting us at other locations.
So what that means is you could have people Vancouver working,
which is happening due to the tax incentives,
or like [INAUDIBLE] faxes in Quebec, and Montreal,
and everywhere else.
But the storage is living at some central location.
So this is the product line.
We have the Google Virtual FXT.
And that has a certain size of DRAM and SSD.
And then we have the hardware off to the right.
And we have three models right now,
and the farthest one the right is the 4850.
It's the highest performing model
because it's full of SSDs.
The flagship product is the 3850,
which has a mixture of SSD, DRAM and SAS drives
for the coldest data.
What we do is, since we have these multiple different types
of media, we actually move data, demote it,
promote data back and forth, within those media types,
depending on what the client's needs are.
So that in mind, we also have an NVRAM card
in the bare metal machines.
So some of the tests we've done with the virtual image that
runs within a Google compute is that the speeds are really,
really close to the low-end bare metal machine that we have.
The only thing that's different is the writes.
It's because there's no NVRAM card in Google Compute yet.
So we have to commit those writes in the SSDs.
But other than that, the reads are maybe 80% or 90%
of what the bare metal machines are.
So just to recap, the connector that we
use to talk to the storage is NFSv3,
or we use the S3 API, which is what
we're using to talk to the Google Cloud Storage.
We can scale the bare metal cluster or the virtual cluster
up to 50.
Not that you would do that.
You have to have 150,000 nodes or something to be able to spin
up your cluster up to 50.
One of the things that we probably
should have had a slide on is the statistics.
And somebody mentioned about statistics a little earlier
on this morning.
We have about 10,000 statistics that we can present.
It's just dizzying, the things that you gather.
And the reason why we can gather these statistics
is we're in a data path, of course.
But we have our head above water and below water,
so to speak, because we understand what the clients are
doing and we also understand the back-end storage device,
whether it's an object storage device or a NAS product.
So we can tell you what's happening with the core filers.
We can tell you what the clients are doing.
And more importantly, we can drill right down
to tell you what the hot clients are in any particular point
in time.
We can tell you the rate of I/O and what that I/O is.
We can drill down even deeper and tell you
what the clients are doing.
So we can give you a list of the hot clients,
and we can tell you what type of activities they're doing.
Are they doing reads?
Are they doing writes?
Are they doing directory updates?
We can tell you the path of the file to do that.
You can gather that through our dashboard, our UI,
or you can actually use our API.
We have an API based on XML-RPC that you
can use to gather all that data and put it into any other tools
that you might be using today.