ArcGIS Enterprise: Architecting Your Deployment

this is a relatively advanced session I'm going to be covering a lot of different topics around architecting your deployment of our case enterprise many many things go deep and then also very broad so I want to get a feel for everybody in the room do you think of yourselves primarily as developers GIS analysts IT administrators so developers this is the dev summit after all all right IT administrators meaning you're responsible for installing configuring running the software so those of you who had your hands up for both of those do you consider yourself more of a DevOps type shop or is it no I just wear many many hats DevOps many hats lots of people's with many hats job security so this session is definitely geared toward the IT administrators in the room for those of you who don't feel like that's necessarily you I hope you still stick around okay hopefully you'll hear about a great many different concepts that you can use to gain a better understanding of your actual implementation or your future implementation or simply work better with the IT people within your organization about what is it we need to do there's all this software atracsys releasing new software and new components you need help getting it all set up so that is the target audience for what I'll be talking about here for the next hour zone my name is Philip Edie I'm the lead product manager for RJ's Enterprise I moonlight as somebody else who knows what he's talking about technically with me as Shannon here it found in front also product manager on the arches Enterprise team so afterwards we'll do plenty of questions at the end if I don't go too long but afterwards come up and talk to us shannon and myself and we'll try to answer your questions we'll also be in the showcase later on all right with that set like I mentioned I'll be covering a lot of different topics in a decent amount of depth so don't panic if you feel overwhelmed at the end of the session it's a little bit by design I want you to know a lot of things about a lot of different things but I also want you to know that you should go and follow the documentation don't think that you can just sit down and necessarily go through all these topics over the course of one hour now you're going to be an expert I cannot make you an expert what I want to do though is make you're aware of all these things so you can go back and find the information you need hopefully there's also going to be a lot of good information on the slides themselves a lot of information that is in the documentation but maybe just be collected up a little bit more easily accessible here so when the slides are made available on the conference website here in a couple of weeks you can also go find those you're also free to take pictures although I will give you the slide all right how many of you attended any of the introducing RJ's enterprise sessions or similar one you're following me around I apologize I will repeat myself a little bit for those of you who didn't I just want to quickly go through some of the ideas within RJ's Enterprise 2 different software components I'm going to assume that most of you if not all of you are existing our GIS 4 server customers users of server so you're probably very familiar with the RJ a server software component itself as well as the web adapter web adapters been around since ten-one arcgis enterprise is first of all the new name for arches for server you don't have to say for any more RJ's Enterprise flows a little bit more smoothly and it's a product that contains multiple different software components specifically for software components there's of course RJ a server itself it has not gone anywhere still there don't worry portal for RJ's is another key component of the product and then of course there are some of the supporting components like the web adapter that your familiar with and also Archie a datastore which has been around for a couple of releases but depending on where you are with your deployment you may or may not have started using it our GIS enterprise that 10.5 is fundamentally designed to use all four of these components together that's the first thing that I will talk about here which is the arches enterprise space deployment but like I mentioned all four of these components have been around for a while they're not new at 10.5 but depending on your deployments they may be new to you a new thing a 10.5 was also this idea of server roles let's gift like users can have a role within the system servers can have a role within the system there's a single software component called rjs server that depending on what license you applied to it gains different sets of capability that's a new concept at 10.5 specifically I'll be talking about these four different sets of capabilities there's the GIS server itself which is probably what many of you think of as just traditional rjs server capabilities map services feature services geocoding geoprocessing and so forth and then we have teo event image and geo analytic servers but the key part here is there's just one thing you install you download arcgis server that's the installer you click Next Next Next maybe you even use something fancier like chef's automation or something to install everything but you install this component you give it a license then it gets a purpose in life now it can do services so I'll talk about the individual server roles and how to think of them when you're architecting your system what are the specific recommendations unique to the individual server roles because they're not all the same there may be one set of bits and bytes written on disk but they do very different things and behave in very different ways so one software component multiple server roles let's start with the base deployment of our JS enterprise it consists of these four components so gone are the days of stand-alone servers where you just install rjs server now many of you say well that's what I have and that's ok but RJ's Enterprise beginning with 10.5 it's fundamentally designed for the newer capabilities to come in through the base deployment and then adding additional capabilities as you need to the base deployment the ArcGIS server component has a key part to play in the base deployment it's what you set up as what's known as the hosting server so when you or your users hand over data to the system whether it's dragging and dropping a CSV file onto a map or performing analysis within the portal that data has to go somewhere that result has to go somewhere and ultimately it has to be hosted by something the hosting server that's what it does so this is where all the all the services that come through actions within the system are actually served out of there's a rest endpoint that's coming out of the hosting server hosting server is also just a traditional GIS server itself so you can also publish your own traditional services from data that you're referencing as opposed to handing over copies to the system so it plays a couple of different roles here the next component is portal har gif many of you will probably think of portal for GIS at that web app the home app as we often call it because it's slash home in the URL it is of course that and it's a location that you can use directly at the user but it's certainly also the back-end infrastructure that powers all of our applications all the applications and you build on top of the rjs platform this is where the group and sharing mechanism also comes in identity access control and authorization is hand let this here then we have the ArcGIS data store like I mentioned when hello there we go when data is handed over to the system it has to go somewhere so the rjs data store is a software component they'll be built for that purpose our data data store comes in three different types each designed for different types of data so typical feature data that CSV file the results of your analysis that created vector data output goes into the relational data store think of this that's the logical equivalent of a managed Enterprise geo database it just happens to be a component that comes with the system so there's not another our DBMS that you have to explicitly manage yourself we come with that component because we can make a lot of assumptions about how that component works we know exactly what the software is the configuration because the system manages all of that for you the second type of data store is the tile cache data store and despite its name it's not raster tile in fact it's 3d tiles when you publish out your own multi patch data or other types of 3d data that we support these days as scene layers and create a web scene internally we build a tile cache off of that 3d data that's what goes into that data store type and then finally we have the spatiotemporal big data store this is where things like geo event server can archive large volumes of data it can ingest data at a speed far beyond what a traditional RDBMS can do and it's also where geo analytics itself can write the results of gear analytics output to so all three of these different data store types have a specific mission and purpose in life and finally we have our key is web adapter this is a well-known component for most of you I would assume it's where we do certain types of security integration IWA PKI all the web tier security relies on the web adapter it's also a simple software load balancer so you don't necessarily have to have your own fancies f5 hardware load balancer or something along those lines we provide a load balancer with the system the base deployment is described in our documentation so if you go to the new 10:5 dock you can go and see all of the things that I just talked about laid out here are the different components this is what they do this is what it means and I strongly encourage you to use this documentation whenever you can let's go through the individual choices you have when choosing how to set up your base deployment rj's Enterprise has a very flexible deployment pattern it can be installed in basically any software environment where you need the system requirements itself that's on-premises in your data center under your desk in the cloud private or public cloud I won't talk about that here in this session but I do want to make the point that you don't necessarily have to think of RT as enterprise as being the on-premises solution and RJ is online is the cloud solution RT is enterprise run very what runs we're very well in the cloud in fact it's much much easier to run in the cloud than virtually anywhere else what you do need to make a choice of no matter what environment you're running within is do I want everything on a single machine that's simple or do I want a multi-tiered deployment do I install my portal on one machine my server on a second machine my data stores on a third machine or maybe a fourth machine how many machines do you have how many machines do you want I mean do I need that's choice number one for the base deployment no matter what particular deployment pattern you choose it's the same logical architecture there's a web adapter for the portal there's the web adapter for the server site and then you have the ArcGIS data store so when is it appropriate to install everything on one machine many times this can be depth test environment that's very simple and easy to get started with but they can absolutely also be appropriate for small production environment it doesn't have to be that as soon as you have a production environment you install everything on multiple tiers if you're a small shop with a limited amount of users or simply big machines you can and are perfectly fine running everything on one machine so when do you need to go multi tier well one of the challenges is that you may at some point have to scale out and it's much harder to start scaling out if you've already installed everything on one machine because now you have to start scaling out the individual tiers and you have to break things apart so that's the first thing that I want you to think about when you first start looking at RGS enterprise and your deployment pattern do I ever need to scale out in the future and maybe that's a hard question to answer but nonetheless if you suspect that you may have to that's an indication you might want to start looking at a multitude deployment from the get-go so setting up the base deployment there's a number of different steps you have to install all the software and then all the software has to get configured together all those deceptively simple lines between the components yes you get to do that so what's the first step well after installing all of your software a key part is to designate your hosting server site you've installed our j/s server you federated ArcGIS server with portal and then you tell the portal this Riverside is going to be my my hosting site so portal knows this is where I send all of that hosted data data that gets copied over to the system before you can do that you need to configure the ArcGIS data store with your server-side you need to install the relational data store and the tile cache data store now that sounds complicated I don't want to scare anybody off though we have a tutorial so you can go again to the documentation this lists out every single steps that I just talked about in detail step-by-step for an all-in-one deployment so this on a single machine you're setting everything up if you follow this tutorial if you want to follow this tutorial for a multi-tiered deployment not a huge leap to simply think of all the components on separate machines if you're running in the cloud like I mentioned it's even easier we have cloud formation templates for AWS that does exactly this for you and we have the cloud builder for Microsoft Azure and it is literally going through a wizard in the cloud builder saying I want one of these I wanted on one machine I wanted on multiple machines walking away for half an hour 40 minutes go to lunch and it'll have done everything for you so there's lots of options for how to get all of these things set up and installed but at the end of the day whether you do it by hand or through one of our automated options you have a base deployment in place for you to work with so when we talk about the different capabilities of our GIS Enterprise that is referring to what you can do with the base deployment in place there's additional capabilities that we can add to the base deployment using the other server roles such as Geo event image and geo analytics lots of things that we filled over the past couple of releases fundamentally require the base deployment all of you are most likely publishing your services from arcmap today over the past couple of releases we've added the ability to publish services from arcgis pro arcgis pro has a lot of new functionality parameterised query layers display filters great things that you've been asking for over the past several years Pro publishes to ArcGIS Enterprise not standalone servers so that requires the base deployment to be in place Pro works with federated servers so everything is tightly integrated with identities and access control in one place so once we have the base deployment in place when do I need to stay allow those individual tiers the portal tier the server tier the data store tier so let's take those one at a time the portals here is fairly simple you very rarely have to scale it up chordal is not very CPU intensive it uses a fair amount of memory depending on your usage patterns the amount of users and so forth but that's really about it it's not a super heavyweight component portal supports having a highly available environment meaning two different machines handling the load so if one of them goes down the other can automatically take over but the way to scale portal is simply scale up scale up the machine that is running on adding more memories or adding more cores if you truly run into bottlenecks at that level you don't add additional machines for additional capacity like you would with rjs server with our GIS server you have a couple of different options and these are the same options that you've had with the server component since 10.1 things have not fundamentally changed for a while and how you do this you can of course scale up you have a single machine you need more capacity to add more capacity to that single machine if we're talking physical machines that may not be so simple if we're talking virtual you may simply be able to increase the size of your VM but of course you can also scale out so instead of just scaling up scaling out by adding multiple machines to your site all of the machines within a single Archaea server site perform the same duties they have the same services published to them you're simply adding additional capacity so when it requests come in they can be spread out over multiple different machines you can scale out r.j. a server with n number of machines however many you need to support whatever the services you are publishing and the load that you're pushing on it so specifically for the base deployment the hosting server is an interesting thing because it's not just your services things you have explicitly published using arcmap or probe it's also all the things that users are doing within the system such as performing analysis beginning with ArcGIS for server at the time 10.4 we had the out-of-the-box analysis tools users can go within the map viewer in the portal and simply perform analysis simple GIS analysis in there well that analysis has to happen somewhere that's what fundamentally again what the hosting server does so now we have what amounts to GP jobs running on the hosting server if you have a lot of users running a lot of analysis you will need to look at your hosting server site and make sure you have the appropriate capacity new with ArcGIS enterprise that 10.5 is insights for arteria you've seen that demoed staged here on Tuesday insights is a fantastically cool and new type of web application but it's not just a pretty JavaScript app it has a server back-end component to it that server back-end component runs on the hosting server so you need to be aware of the load that you're putting on the hosting server for the actual number crunching that happens within inside for ArcGIS so when do I need to scale out the RJ's data stores here argue estate asur like I said have three different data store types within it and they need to be scaled for different reasons the relational data store that's where data from hosted feature layers goes again that csv files that you somebody dragged and dropped on to a map with it within the portal map viewer that goes into the data store so it's an interesting thing that we can scale massively in the number of hosted feature layers if your long term server users serve server administrators you'll know all about our TOC processes they use a lot of memory don't think not yeah hosted feature layer film it's a fundamentally different architecture different back-end implementation doesn't use the stock processes it's simply Java code that we're running but the way that that Java code works is that well we rely on the database to do a lot of the heavy lifting we're just streaming data back so you need to understand that even though you may have 10,000 hosted layers that's not using a lot of server memory on your hosting server itself but the back-end database may be doing a lot of work to try to keep that data within memory and so forth so you need to monitor your data store your relational data store for memory usage if you have a lot of users using a few set of services hosted services that is optimal because that's fundamentally what the system is designed for out of 10,000 closes layers the odds are there's only a fraction of them that are actually in hot uses at any given point in time but the more of those services that are actually in use the more there's memory and CPU consumption especially the database tier so something to be aware of and something to monitor as you open up self-service mapping to your organization's and lots of those services are generated be aware of this here and what is going on there the key thing is to always monitor for bottlenecks the tile cache data store like I mentioned it's used by scene layers or 3d data that you publish out during the publishing process there's two things that happen the data it gets handed over to the server well to a system the server starts crunching through that data to fill the tile cache at the point in time of publishing your scene layer that takes up CPU on the hosting server itself but once it's built just like a cached map service static data that's now being stored and streamed back to clients upon request that data goes into the tile cache data store that's where you start seeing memory consumption on the tile cache data store if you have a lot of different scene layers that are all being hat actively used they're all hot in memory you will need more memory on the tile cache data store to so now we have a basis point you don't need to scale the portal tier very often you need to be aware of what's going on at the hosting server tier and then you need to understand what's going on at the data storage here now we go beyond that and there can be lots of different reasons for why you need to go beyond the base appointment one is I already have the GIS server but it sounds like I want to isolate certain features certain services from the hosting server itself workload separation let's say I have a lot of insights users I don't want my other map services the ones that are powering the rest of the organization to be impacted by when somebody performs analysis within insights or within the portal itself that sounds like a bad deal you can add additional GIS server site to your deployment and you don't have to stop at one additional site lots of you have multiple sites for one for map services one for a different set of map services maybe one for geoprocessing services because well TP can be heavyweight by itself isolating those things from each other it's up to you as system architects to understand your particular usage pattern and when does it make sense to create a separate site for certain features you have the flexibility to go all in one or spread across as many different sites that you want and PL you can actually maintain there's of course trade-off and then another reason to add additional server sites to your ArcGIS enterprise deployment are for those additional capabilities the image server Keo event and geo analytics those are all designed to be set up a separate site now at this point I often get the question well can I have some of those other server roles on a single site maybe on the same side as my hosting server maybe just commingled with a GIS er the short technically correct answer which developers you appreciate that this yes you can the longer answer is don't the even longer answer is don't unless you really know what you're doing so fundamentally tu analytic server should never be put on the same machine as anything else you analytic server sucks up at every single resource it can get this hands-on because that's what it's designed for all the memory and all the CPUs you can possibly give it geo event server has a similar type of pattern it uses a lot of CPU potentially for all those events streaming into the system so generally you would not want to combine geo event with anything else now once we get to image server as we'll see in here just a second there's a little bit more wiggle room but in general image services traditional image services have a tendency to also be CPU intensive depending on what you're doing with them and the amount of data it's a very good candidate for a workload separation and unless you have very good reasons to and really truly know what you're doing because you've tested it out ahead of time I would not recommend putting it together with any other other server roles let's dig into the different server roles first I want to just make the point that you can have many federated sites within a single deployment the common misconception or delete the question I hear fairly often is I didn't know that I could have multiple server sites federated with my portal it's not a one-to-one it's a one-to-many so you have full flexibility but the different server roles have different recommendations on scaling out scaling up that I'll go through here in just a second so no your server roles we have the four main server roles that I'm going to talk about in this particular session this is where the session gets a little bit text heavy on the slide that's mostly a cue to myself but also because I want you to be able to take these slides when you get back to your offices and make use of them so they're a little bit of a reference stock cheat sheet for what's also in the documentation itself the GIS server is what all of you already have today just a traditional rjs server and you can create as many server site for the GIS server as you need as many or as few and like I said it can depend on exactly the types of services that you have the different SLA is you may have maybe there are certain says the services that absolutely just have to be up and running a hundred percent of the time you want to dedicate some infrastructure and resources to those maybe some are slightly less important so they only get a single isolated machine that can do whatever it is it needs to do isolating GP from routing from map services completely up to you to understand your usage patterns image server is a little bit different for traditional image server functionality what used to be image extension for server meaning publishing dynamic image services from mosaics data sets it's similar to the GIS server itself if you have different sets of dynamic image services that have different SLA s or simply you'd want to isolate them from each other you can create as many sites as is appropriate for your setup for the new raster analytics function what we've introduced at 10.5 there can only be a single site that's designated as this is the site where browser analytics functions run so that site is something you have to scale up or scale out to give additional resources we don't today in the product have a way to say well some raster analytics jobs go over here other vaster and lakes jobs go to this other site all raster and latest jobs goes to one specific site that you point out the same thing is true for geo analytics there's one site for geo analytics within the deployment and that site can be scaled up and scaled out as needed you tell the system this is the site where geo analytics jobs will run and then finally just because we need to have as many different combinations as we can geo event you can have as many sites as is appropriate for you depending on how many streams how big your machines are how many events per second they can process if you do need to scale out because you have many separate streams and you can't handle them all on a single machine we you can add additional site at ten five and Pryor's the strong recommendation is to use single machine site so if you're in the Geo event realm that's an important note that's a bit of a change in recommendations from previous releases so I do want to make make that make you aware of that and point it out if you haven't seen it already so just before I move on and talk about the individual site I want to show what I meant by being able to designate a server site as a raster and Liga's raster analytics or geo analytics so this is actually the system that we used for the plenary on Tuesday this is the system lauren but during her demo of keo analytics of again so in this setup i have two separate server site federated with my portal the reason the second one is showing us an exclamation mark is because it's running in the cloud and i shut down the machine to save money you have two different sites here one running one not when you look at the hosting server options here you can see in my drop-down I have those two sites available I can say this particular site is my hosting server site if we scroll further down new at ten five you'll see these two options one for do analytics ones for raster analysis here for geo analytics I selected that other site said this is my do analytic site so this is where the one side you want to use for that purpose is shown and breaking my own recommendation I also have that same site set up for raster analytics tightly-controlled demo environment so that's how it actually shows up within the user interface here I'm designating a site for a specific purpose so let's take a look at image server I already alluded to this a little bit image server has two distinct capabilities the traditional dynamic image services you have large collections of imagery set up with mosaic data sets and the ability to publish those out at the image services and perform on the fly processing just in time as a request comes in we read the pixels do the mosaicing apply the raster functions and return an image to the client it's not persisted anywhere new a 10.5 is raster analytics which you also saw demonstrated on Tuesday during the plenary vinay showed how we could process massive amounts of pixels through large collections or simply high resolution or large geographies this is about performing that analysis at source resolution not just the display resolution of a client coming in but at source resolution and then persisting the results on disk so this is where you can use multi-threaded distributed computing and use a raster analytic site for that so one thing to consider here is do I want one image server side doing both of these things or do I want to split those things the simplest option is of course just have a single site you have all the components of the base employment from before your web adapters to your hosting server with a little house icon portal the data source and now we've simply added one more RJ's server site a logical entity for those different image servers going beyond that you could take that extra step and splits dynamic image services off from your raster analytics features often this would be the recommended approach because again while you're doing raster analysis while you're processing all of those pixels that is designed to take up perform as fast as possible and take up all the available resources you most likely don't want to have that impact all of your other running dynamic image services geo analytics can be compared to raster analytics but there's some very specific requirements and some recommendations that I want to highlight because geo and Linux is brand new I want to make sure that you're all aware of some of those those details as I mentioned there's just one side for geo analytics that one PC you don't have to worry too much about whether you want multiple sites or not to set up keo analytics server you also have to have the spatiotemporal big data store within your deployment so when you install rjs data store that's the software component you get a little wizard that says you want relational you want tile cache you want spatiotemporal part of the base deployment was relational and tile cash now we have a feature that works requires spatiotemporal trick here is spatiotemporal big data store while in this case I'm saying it's used by geo analytics it's always hooked up to the hosting server RJ's data store is always connected to the hosting server and through the Federation and the trusted relationship between all the different components Keo Analytics will automatically use that and we'll see why that is the case here in just a second as we cut to geo event spatiotemporal big data store has a completely different usage pattern than a traditional RDBMS they can use even more memory if you believe that's possible we recommend using at least 16 gigs of memory for your spatiotemporal big data store and a maximum of 64 quark quark of the technology doesn't scale beyond 64 so that's just a waste at that point you can add multiple notes of the spatial temporal big data store whether you want multiple notes for high availability having copies of the data across multiple nodes but also for scaling out the more nodes the higher throughput you can push in to the data store so if you have large amounts of imagery or observations streaming in through your geo event or you have large amounts of geo analytics servers writing results back out you may need to scale out your spatiotemporal big data store now the next question for geo analytics is how many machines do I need and my answer is that depends and I'll just leave it as that one thing to truly understand is that it does not always equal bass or processing time by throwing more hardware at it that's why it depends it depends on the size of your data set it depends on how fast you wanted to go of course but it also depends on where does that data come from what's the format are they CSV files or are you connecting up to HDFS or hi can you actually stream the data from wherever it's fitting fast enough to keep all your machines busy if your bottom left on your network it doesn't help to add additional compute power because you can't actually get the data to the compute lots of different things we take into account there but I do want to make the point that you don't necessarily have to have hundreds of cores or many many different machines in fact that was the point we were trying to convey with Lauren's demo on Tuesday at the desktop user or performant traditional desktop style analysis a single machine of Geo event sorry geo analytics can actually provide a huge amount of value she was able to process through 54 million records worth of CSV based data in about 4 minutes on a single 8 core machine so depending on what kind of data you have and your scenario you may not need anything more than a single machine if you need to scale beyond that you have to look at your data and do some proof-of-concept so the simplest version of a Geo analytics setup looks like this again we have the components from our base deployment we've added the spatiotemporal big data store sitting off on the left and we've added a single machine of tío analytics this can get you really really far start with this it's not complex there's no huge system architecture that goes into figuring this out and see how far you can come within your scenario after this the next step is to scale out that Geo analytic server site and that's where it can get complicated depending on what it is you need to do how much data you have how many concurrent jobs you need and so on and so forth see everybody's taking pictures let's move on to P o of n so geo event server provides the ability to create the few event services and also stream services for visualization purposes as I mentioned the strong recommendation for 10-5 and prior is to use a single machine site for geo event you can have multiple single machine sites but within each site stick to one that means that each machine or each site need to be powerful enough to meet the peak demand that you're going to put on it however many events per second observation streaming in you need to be able to handle on that one machine for that set of streams in other words if you're if a single stream of input data is too much for your machine to handle you need to scale that machine up as opposed to scaling it out to handle multiple streams you can scale out by adding additional sites when you're archiving large amounts of data from geo event that's also the spatiotemporal big data store but it's not a requirement in that sense if you have fewer than a couple of hundred events per second that can typically be handled by a traditional RDBMS as well so it's your choice if you want to archive into your oracle your sequel server or do you have something beyond what you can scale to meet there and then you can use spatiotemporal big data store means there's a couple of different options for geo event and what your deployment can look like the simplest version is just the base employment plus a single machine geo event from here you can write to the relational data store within the base deployment or your external database Enterprise to your database of a choice your own sequel server your own Oracle Postgres the whole list going from here you might just add spatiotemporal big data store single machine geo event but writing the our archive of observations to spatiotemporal big data store the next step from here would be to expand out with additional geo event server sites one machine at a time at that point you're almost certainly in the category of wanting to write all those observations to the spatiotemporal big data store you very quickly can saturate a traditional RDBMS alright i'm key takeaways how am i doing on time much faster than anticipated some key takeaways are Jay's Enterprise is designed for the federated server model there's lots of newer functionality such as raster analytics and geo analytics that's required but there's also something much more down-to-earth which is simply using ArcGIS Pro there's lots of new capabilities in Pro and I want you to be able to take advantage of that for that you have to have the federated server model in other words it's not just server it's the whole arches Enterprise installation with the base deployment in place understand what the base deployment means those different components how to scale them out when to scale them out don't necessarily make it too complicated too quickly it doesn't have to be hard I know it can seem overwhelming at least based on some of the questions we could once you are ready to go beyond the base deployment with geo analytics or some of the other server roles look at the information that I went over here and talked about what are the individual roles how do they scale out what do I need to keep in mind what did I start off by saying don't panic start small start with the base appointment you can start on a single machine if you're setting it up yourself that's by far the easiest if you're setting up in a different environment using an automatic technology that is still a super quick easy way to get started as you plan out for your organization a production environment ask yourself will I need to scale beyond what I can handle on a single machine if so I should start off with a multi-tiered deployment simply for ease of scaling out further down the road all right for once I didn't go long which means I have time for questions hopefully this was helpful I'm really happy you showed up here this afternoon I have about 10 minutes for questions there's usually lots of great questions about system architecture at this point but thank you all right [Applause] question down here in front so that I'll try to restate the question I start off with my hosting server a single site for both hosting and use and traditional GIS server duties now I add a separate GIS server site how do I now tell the system to start using that separate type for certain things for that you will have to publish your your additional services to that site explicitly say this set of services goes over here hosted services always go to the hosting server all by definition everything else things you're publishing from arcmap or pro you have the explicit choice of saying this map service this feature service this locator this TP service goes on this particular site it's the licensing for this administered by core or named user the server roles are all licensed by core by capacity the DIA server TM event geo analytics and image are all old by capacity by core I'll try to restate the question tell me if I understood you if there are multiple different installs or ways that I get the different capabilities there's one software installer you download the rjs server installer you've run that installer and then the last step is I need my license file once you give it the GIS server license file now it has GIS server capabilities enabled you can now publish map services feature service and so forth if you give it a do analytic server license it now can do Geo analytics it can't do anything else and that's actually a new concept at ten five right if you connect with let's say arcmap to a geo analytic server and try to publish a map service will say no that doesn't work am i what no so the question is doing it do I need a separate portal for different hosting servers different port different data stores the answer is no there's a single portal that has one or more different rjs server sites for different purposes the first such site is the hosting server site itself all of the data stores connect up to the hosting server site the different data stores are managed from within the system so all of the other machines within the whole topology are automatically aware of those those data stores q analytics server when it gets connected up simply knows because it's part of the overall system that there is a spatiotemporal big data store somewhere off on a different machine I have a hosting server in the DMZ and it can't see inside the network with that cause of problem depends on where your clients are where the other components are that can get complicated the system is designed that all the components can see each other right they need to be able to see each other then your clients need to be able to access the rest endpoints of each one of the server side so any server side has to be accessible to the end client I'll restate so publishing a vector tile layer is an example of something that requires the base deployment you need to portal you need your hosting server and so forth Publishing a vector tile layer is simply handing over the tile package to the system and it gets automatically made available as a layer we can we can probably finish that one off line and draw some lines on a whiteboard I like drawing on whiteboards all right question off on the side so the question is if I need to scale out at the data store tier in this case the spatiotemporal big data store but it's relational or tile cache as well what do I need from a licensing perspective nothing for Victor there's no additional licensing associated with any of the data store component it can grow unbounded yes because why does it need to grow unbounded well because you have Geo event or geo and lytic sitting in front there's no additional licensing associated with last question and I think we'll wrap it up so the question is you're using a partner solution in this case city works and they have an SOE and will that fit in here I hope so I don't know the city work solution specifically so I can't can't answer that definitively but to the extent that it's an SOA that runs on top of the GIS server yes you can install a a we use and use that within the federated model thank you so much [Applause]

Channel: Esri Events

Views: 7,275

Rating: 5 out of 5

Keywords: Esri, ArcGIS, GIS, Esri Events, ArcGIS Enterprise, deployment, server roles

Id: WxUFh0c9hNw

Length: 55min 18sec (3318 seconds)

Published: Thu Mar 23 2017