Was wondering if anyone has already setup their ArcGIS environment in Azure and how they deal with connectivity from on-prem ArcGIS clients. E.g. any bandwidth issues or considerations? Any info is welcome.
Thanks,
MM
Very similar situation here. We keep unearthing small issues with security and configuring the environment, so heavy testing has yet to occur.
My primary issue I've yet to test-out and determine a path forward for is dealing with our current need for multi-user editing for our local team (onprem ArcGIS Desktop) while still having an enterprise GDB (and therefore SQL Standard instance) in Azure for publication of map & feature services [without needing 2 ArcGIS Enterprise licenses and 2 SQL Server instances].
My ideal is that our local connections to the enterprise GDB on Azure will magically have sufficient speed/drawing times. If that doesn't work out I'll have to rethink our data model/data flow. This could leave us in a situation where each workstation has an SQL express instance to host 2-way GDB replicas and then implementing scripts run via task scheduler that keep everything synced up. Its far from ideal, but that may be the reality I'm facing depending on how testing works out.
There are a number of other factors at play here; I'm happy to compare notes with you. I'm a bit surprised there isn't more discussion about this yet but I suspect most organizations have well-funded GIS infrastructure which takes care of many of these issues.
I have the same problem with the ArcGIS Desktop and Azure SQL Database, still looking for a solution.
Has anyone looked into whether the new Branch Versioning workflows could work for this scenario. From what I understand (as of 10.6) this would require editing feature services which could be hosted in the cloud via ArcPro (not yet/ever? available for desktop). I haven't tried this yet, just doing some research of my own as we plan for helping clients upgrade.
I'm also looking for info on this topic. We are about to start our move to Enterprise 10.6 and putting it in Azure.We spec'd out an instance of Azure SQL to host our enterprise gdb. But I'm reading here in geonet as well as this doc under limitations http://enterprise.arcgis.com/en/server/latest/cloud/azure/database-requirements-azure-sql-database.htm that we will run into trouble when our users fire up arcmap/pro from their laptops and try to make db connections/work with features in the e gdb.
Is this true? Any recomendations?
I'm wondering if we need to scrap our plan of moving to Azure SQL and stick with an instance of SQL server.
Any insight, rec's or stories are welcomed. Cheers.
Hi - We are also considering using Azure for a GDB, but I think it's really important to be able to connect in arcmap/pro for editing and analysis.
I'd love know what other people have learned/discovered/decided.
Major points to consider; unless you have very deep pockets and have very large pipes to Azure; performance will always be an issue. The typical LAN/WAN interface will be 1GB between desktops to switches to your RDBMS server.
Once you start trying to take the volume of data you would typically have in the eGDB and put in in the cloud; now you are going through things like firewalled or VPN connections, multi-hop connections between ISPs and finally the M$FT cloud.
Make sure the data you are wanting to work with there is designed for that purpose; the more data you have, the more reads/caching will happen and this will slow you down.
Also, consider that some of the Azure & AWS data hosting solutions also charge for throughput, so if you are working with large datasets and will be doing lots of reads/writes that bump that number you might see costs skyrocket....
This is good - thank you!
Collin Johnston Johanna Kraus Lourdes Suman
UPDATEish:
Lots of testing has been done and we're now moving forward with implementation.
To be clear: We're not using Azure SQL (Paas) but are instead migrating all of our company DB resources ( currently in a datacenter and this is not just GIS) to an SQL Server instance (on a VM) in Azure (IaaS), and our (current) onprem SQL Standard instance which hosts our eGDB is along for the ride.
We will have a separate VM hosting ArcGIS Server federated with ArcGIS Portal (so Base ArcGIS Enterprise Deployment).
Previous testing related to eGDB issues revealed the following:
The only viable solution here in order to continue to support multi-user editing on-prem is to stand-up an ArcGIS Workgroup instance (this sits on SQL Express)**. We will then use a 2-way DB replica to sync changes between the two environments.
Now, if you want to talk about handling file data...that's a whole other can of worms....
**If you do not need to support multi-user editing ArcGIS (Desktop) Database Server may have some value to you.
***EDITED: Lots of points of clarity. Happy to provide more details.
So, you are hosting your eGDB on in house instance of SQL so that users can access it through arcmap/pro - correct? Do you also publish services from this DB or do you publish them from the ArcGIS Workgroup instance?
I'll try to clarify:
The local SQL Express/ArcGIS Workgroup instance is only there to support local multi-user editing for our core GIS staff. This is a DB replica.
The parent of this replica resides in SQL Standard/ArcGIS Enterprise in Azure. From Azure is where our feature & map services will be created/hosted.
Does that help explain things better?
Again, if you do not have the need for multi user editing, the following are potential options you could use in order to still support local editing but have your eGDB reside in Azure:
This may help illustrate a few different scenarios you could implement.
Just out of curiosity, how did you end up setting up your Enterprise 10.6 environment?
Yes, this is incredibly helpful. Thanks to all who are participating in this thread. I will add to this as we go forward with Paas testing.
As it stands we have just stood up and pushed to Production our Enterprise 10.6.1 which is hosted on Azure. Due to the inability to use linked servers with the PaaS model for Azure SQL we had to move forward with the IaaS model using a VM in Azure to host our SQL server. Salesforce is replicating to an OnPrem SQL Server so we can query those tables and views into GIS eGDB. Not ideal but it works.
Now I am working on building our Azure hosted SQL (PaaS) using Logic apps to move data from our Salesforce instance to the Azure Hosted SQL directly, no more need for linked server. I'm not too thrilled about what the outcome is going to be based on this thread and others I have read including ESRI documentation itself. I'm hoping my very small GIS user base will be ok using services to edit eGDB data. Otherwise all our users are access our data via map services in custom apps or Portal. But, hey at least I have a working setup now which buys me a bit more time to try and make this work.
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
