Hardware configuration for SkylineGlobe servers

Size: px

Start display at page:

Download "Hardware configuration for SkylineGlobe servers"

Russell Golden
6 years ago
Views:

1 Hardware configuration for SkylineGlobe servers This article provides information for SkylineGlobe server configuration. It discusses various considerations to take into account when setting up and configuring the different server components. Server Configuration TerraGate Terrain Service It is recommended to allocate a dedicated server for each 500 concurrent users. A strong server (e.g. quad core Xeon 16 GB RAM) can handle up to 1000 concurrent users. Operating system: Windows Server 2003 SP2 / 2003 R2 SP2 / 2008 SP 2 / 2008 R2 / CPU: Pentium Dual or Quad core system. RAM: 1 GB for Windows plus 10 MB per concurrent user. For it is recommended to provide 8 GB RAM. Storage: See Storage Requirements chapter. Load balancing: You can set up several TerraGate terrain servers behind a load balancer. Usually these servers share a central storage for the terrain database (MPT). Any hardware or software load balancer solution is supported. Redundancy: In mission critical systems it is advisable to allocate at least one additional failover terrain server, e.g. for a 2000 concurrent user system, it is recommended to allocate a server for each and then an additional fifth server. Since a single TerraGate terrain server can in fact support more than 500 concurrent users, it is also an option to do without the failover servers and rely on the rest of the TerraGate servers in case one of the systems fails. This option is recommended only in cases where the streaming requirement can be compromised for a limited time. DirectConnect projects In DirectConnect projects the terrain server uses the TerraBuilder fusers to process uncompressed terrain data. DirectConnect with MPT sources Special servers do not need to be allocated for the fusers and they can run on the TerraGate Terrain servers. Fuser processing is only required for terrain

2 areas in which multiple optimized MPT sources overlap. Since more than 97% of the requests are served directly from MPT sources while only less than 3% of block requests are from areas with overlapping MPT sources, minimal fuser processing is required. Note: DirectConnect with native sources It is advisable to allocate additional servers for the fusers and to define two fusers per core (e.g., a quad core server should run 8 fusers). The number of fusers needed for a project depends on the nature of the source formats. Compressed formats (e.g. MrSid, ECW) require additional fuser processing, as does reprojection of the sources to the project s coordinate system. To estimate the number of required fusers it is recommended to test a small TerraBuilder project with the sources, create a small section of the MPT over the network and measure the number of blocks each fuser processes per second. For example, on a medium configuration computer for fast sources (e.g. tiff no re-projection) a fuser can process up to 20 blocks per seconds. Slow sources (e.g. Mr. Sid with reprojection) are processed at a rate of approximately 2-3 blocks per second. Caching reduces the necessity for fuser processing. When a block is requested for the first time, it is processed by a fuser and then cached. Future requests for this block are delivered from the cache (MPT) and require no fuser processing. Thus within just a few days, almost all required fuser processing will be completed. Currently the only way to determine the ratio between fuser requests and cache requests is by performing small scale test of the project. Example for DirectConnect fuser analysis: HW: 1 TerraGate + 3 quad core fuser servers Total number of fusers per server: 3x8 = 24 fusers Total number of blocks per fuser server (average of 6 requests per second): 24*6=144 Ratio between cached requests and non-cached: 2:1 (2 cached and 1 not cached, so only 1/3 of requests need to be processed) Number of requests a fuser server can handle = (144*3) = 432 blocks Number of requests per user: 2 (see Bandwidth Allocation) Total number of users the TG and three fuser servers support: (432*3)/2 = 648 users TerraGate Feature Service (SFS) It is recommended to allocate a dedicated server for each 500 concurrent users. A strong server (e.g. quad core Xeon 16 GB RAM) can handle up to 1000 concurrent users. Load balancing You can support a cluster of TerraGate feature servers behind a load balancer. The servers must share a central storage.

3 Redundancy In mission critical systems it is advisable to allocate at least one additional failover feature server, e.g. for a 2000 concurrent user system, it is recommended to allocate a server for each and then an additional fifth server. Since a single TerraGate Feature Server can in fact support more than 500 concurrent users, it is also an option to do without the failover servers and rely on the rest of the TerraGate servers in case one of the systems fails. This option is recommended only in cases where the streaming requirement can be compromised for limited time. SkylineGlobe Web Application (EWP) The SkylineGlobe website is an ASP.Net/IIS website. A typical server can handle hundreds of users. For large scale projects (500 concurrent users and up) it is important to allocate special servers for the website (IIS), as well as additional failover servers. For small scale projects it is sufficient to allocate two servers, each running both the website and the feature server. The servers can then be used for load balancing and failover. Database The SkylineGlobe EWP application uses a management database to manage the website structure and the user information. The SkylineGlobe EWP application works with an Oracle or SQL server database. The size of the data depends on the number of potential users but usually it is not more than a few gigabytes. If the Gazetteer data is installed it adds 2.5 GB. In many applications the feature data, and sometime also the raster data is also streamed from a database. This data can be located on the same database as the SkylineGlobe management data or on a separate database. Bandwidth Allocation The configuration described below is based on a SkylineGlobe application with an average of 8 minutes per user session. Applications with longer sessions (e.g. city control applications) will reduce the average user data consumption per second from the terrain and feature servers. In general, during short sessions the user zooms into high quality areas and navigates around. In longer sessions, after the initial browsing, the user focuses on an area of interest and therefore pulls less data from the SkylineGlobe servers. The nature of the application determines the user browsing behavior and thus the average bandwidth and storage requirements. Note: It is important to verify that the Load Balancer can handle the traffic load. TerraGate For a smooth navigation experience for internet applications we recommend allocating 300 Kbits (37.5 KB) per second for each concurrent user. This will satisfy the average bandwidth requirements of an average viewing session that includes periods of panning (requiring higher bandwidth) and periods in which the camera is zoomed in on a specific area (requiring lower bandwidth).

4 300 Kbits represents an average of 2 data blocks per second, with each block approximately 15 KB. The block size will vary during a viewing session depending on whether the camera is in motion. When the user is panning and zooming around in the 3D View, TerraExplorer usually requests small blocks (128x128 pixels of around 8 KB per block). When the camera is static, zoomed in on a particular area, with only one block required per second, TerraExplorer usually sends requests for large blocks (256x256 pixels of around 40 KB per block). In fast Intranet environments it is possible to allocate higher bandwidth per user for an even smoother, more seamless viewing experience. TerraGate Feature Service (WFS) To calculate the recommended bandwidth allocation for the feature server we must take into account the number of feature layers the application displays and the complexity of each layer. In a fairly complex environment (SkylineGlobe.com), the feature server s bandwidth requirement generally parallels that of the terrain server. The average bandwidth requirement for an entire flight session of 3 feature data blocks per second per user is 300 Kbits (37.5 KB, with each block approximately 10 KB). SkylineGlobe Website The traffic on the website depends on the complexity and nature of the web application but it generally adds negligible traffic compared to the TerraGate server, except in the case that the TerraExplorer Viewer is downloaded from this server (and not from the Skyline website). The Viewer download size is approximately 28 MB. The traffic this adds depends on the ratio between first-time users (who download the viewer) and returning users. If, for example, the ratio is one new user to every three returning users, 28/4=7 MB should be added per session. For an average session time of eight minutes the Viewer download adds 120 Kbits/s for the bandwidth requirement. Storage Requirements One of the most critical parameters when defining the server architecture is the terrain and feature data storage capability. It is important to verify that the storage can handle the number of requests per second. When building the terrain server hardware it is important to take into account that it will be storing several large files. Generally, only a few large files will be stored, though in some cases, there may be up to several hundred.. On average a single user requests 2 blocks of 15 KB each per second. To serve the requested blocks the terrain server reads the required data from the disk storage.

5 Feature Server The feature serve cache includes millions of small files (blocks). It is important to verify that the storage can handle the amount of files. On average a single user requests 3 blocks (files) of 10 KB each per second. DirectConnect of Feature Layers: If the feature server reads the data from an external database or server (e.g. ArcSDE, Oracle) you should make sure the database/server can handle the number of transactions. Note: Only the first request for a specific block queried from the external database/server is processed. The resulting block is cached so any future requests for this block are delivered from the cache and require no processing. Thus within just a few days, many requests will no longer need to be queried from the external server and processed. Currently the only way to determine the ratio between external requests and cache requests is by performing a small scale test of the project. SkylineGlobe Website The storage required for the website is usually minimal compare to the TerraGate terrain and feature storage. It is recommended to separate the website storage from the other data sets and place it on different disks.

6 Case Study This diagram describes an optional architecture for 1000 concurrent users of a SkylineGlobe Internet server: Bandwidth (peak time) ( + Feature server + TE download)*1000 users = (300 Kbit Kbit + 40 Kbit)*1000 = 640 Mbit per second. Terrain Storage 2 blocks per user * 1000 users = 2000 data requests per second (average of 15 KB per request) Feature Storage 3 blocks per user * 1000 users = 3000 data requests per second (average of 10 KB per request) Terrain DirectConnect In this project the sources are already compressed to MPT. No need to allocate dedicated servers for the fusers. Oracle/SQL Database Up to 5 GB for the application and Gazetteer database. Terrain storage Operational servers Failover servers Load Balancer Feature storage Feature Server Feature Server Feature Server SkylineGlobe Web Server SkylineGlobe Web Server Oracle/SQL Database

7 Copyright 2009 Skyline Software Systems Inc. All rights reserved. Skyline, SkylineGlobe, the Skyline logo, TerraExplorer, SkylineGlobe Pro, TerraDeveloper, TerraBuilder, TerraGate, and the SkylineGlobe Pro logo are trademarks of Skyline Software Systems Inc. All other trademarks are the property of their respective holders. Trademark names are used editorially, to the benefit of the trademark owner, with no intent to infringe on the trademark. Protected by U. S. Patents , , , , Other patents pending. Skyline Software Systems, Inc Park Center Road, Suite 201 Herndon, VA USA Main Tel: Main Fax: General Information: Technical Support: Web:

Getting Started with TerraExplorer for Web

Getting Started with TerraExplorer for Web Version 7.0.0 Skyline Software Systems Inc. Information contained in this document is subject to change without notice and does not represent a commitment on