iPortal high availability configuration |
In general, to ensure iPortal's high availability, only one iPortal service is deployed on a server. So when deploying iPortals on a server, make sure that any port used by iPortal does not conflict with the ports occupied by other applications on that server The The specific configuration of the two iPortals deployed in this example is to be configured in the same way as the following requirements. The actual configuration should also maintain the configuration and data consistency of each iPoral. It is recommended that before putting the portal into production, configure an iPortal, and then copy the configured iPortal product package directly to other servers running iPortal.
The permissions information of the iPortal service agent is saved locally by defult. To ensure that the iPortal is highly available, the service agent's privilege information sharing configuration is required, so that two or more iPortal can be used to share the service proxy information. Then, the user logs in iPortal and registered services, when switching to another iPortal, the service proxy address is still accessible.
You need to modify the configuration file iportal-ehcache.xml (located in the [SuperMap iPortal installation directory] \ webapps \ iportal \ WEB-INF) directory), the code saved in the local will be commented out or deleted, the code is as follows:
<cache name="iportalProxyCache" maxElementsInMemory="10"
overflowToDisk="true" eternal="true"
timeToLiveSeconds="0" timeToIdleSeconds="0"
maxEntriesLocalDisk="0" diskSpoolBufferSizeMB="20"
transactionalMode="off">
</cache>
Open the code comment for the iPortal proxy service's permissions cache shared configuration and modify the contents of the <cacheManagerPeerProviderFactory> and <cacheManagerPeerListenerFactory> nodes, the code is as follows:
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=manual, rmiUrls=//192.168.1.2:4001/iportalProxyCache" />
<cacheManagerPeerListenerFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
properties="hostName=192.168.1.1, port=4001, socketTimeoutMillis=2000" />
<defaultCache maxEntriesLocalHeap="10000" eternal="false"
timeToIdleSeconds="120" timeToLiveSeconds="120" diskSpoolBufferSizeMB="30"
maxEntriesLocalDisk="10000000" diskExpiryThreadIntervalSeconds="120"
memoryStoreEvictionPolicy="LRU">
<persistence strategy="localTempSwap" />
</defaultCache>
<cache name="iportalProxyCache" maxEntriesLocalHeap="10000"
maxEntriesLocalDisk="0" eternal="false" diskSpoolBufferSizeMB="20"
timeToIdleSeconds="3600" timeToLiveSeconds="0"
memoryStoreEvictionPolicy="LFU" transactionalMode="off">
<cacheEventListenerFactory
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
properties="replicateAsynchronous=false, replicatePuts=true,
replicateUpdates=true, replicateUpdatesViaCopy=true,
replicateRemovals=false" />
<bootstrapCacheLoaderFactory
class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory" />
<persistence strategy="localTempSwap" />
</cache>
To achieve the address which registered service agent is also represented by reverse proxy, while hiding the proxy service port, you need to configure the iportal.xml file, located in the [SuperMap iPortal installation directory \ webapps \ iportal \ WEB-INF) folder Add the <proxyServerRootUrl> node under the <serviceProxy> node in the iportal.xml configuration file, set the root address of the reverse proxy service. Because the host in the hosting service address has two display modes: domain name or IP, the <proxyServerRootUrl> node has two configurations:
Method 1: Domain name form
<serviceProxy>
<enable>true</enable>
<port>8195</port>
<proxyServerRootUrl>http://www.myiportal.com[:port]</proxyServerRootUrl>
<httpConnPoolInfo>
<maxTotal>20</maxTotal>
<defaultMaxPerRoute>2</defaultMaxPerRoute>
</httpConnPoolInfo>
</serviceProxy>
Mode 2: IP form, this configuration will make the proxy service address according to the user's current network environment, dynamicly display ip address.
<serviceProxy>
<enable>true</enable>
<port>8195</port>
<proxyServerRootUrl>http://{ProxyHost}[:port]</proxyServerRootUrl>
<httpConnPoolInfo>
<maxTotal>20</maxTotal>
<defaultMaxPerRoute>2</defaultMaxPerRoute>
</httpConnPoolInfo>
</serviceProxy>
After the configuration is complete, restart the iPortal service.
Note: In the above two configuration modes, the [: port] variable indicates the port, and the service listening port can be filled out after the proxy. It can be empty and the default is 80 port.
If you do not Configure Memcached, that is you do not want multiple iPortal service sessions to be shared and consistent, you do not need iPortal's session sharing configuration.
iPortal session sharing configuration, in this example, two iPortal nodes through the shared storage in the cache Memcached session to achieve session sharing, if a server on the iPortal service is stopped, another server session data can still be read from the Memcached cache, so there will not be a problem with session loss.
To satisfy iPortal's session sharing configuration, download the following dependent files and place all dependent files for download into the% SuperMap iPortal_HOME% / lib directory of the iPoral package.
Because the upgrade of iPortal version, the used Web container-Tomcat will be timely upgrade, the specific performance: SuperMap iPortal 7C to SuperMap iPortal 8C SP1 version using the Tomcat 7 series version, from the SuperMap iPortal 8C SP2 version, Is the Tomcat 8 series. so Memcached will download and add different dependent jar files because of the different versions of Tomcat used by iPortal.
Add the <Manager> child node under the <Context> node in the% SuperMap iPortal_HOME% / conf / context.xml file. The contents of the node are as follows:
<Context>
......
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:192.168.120.145:11211"
requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|ico|jpeg|htm|html)$"
sessionBackupAsync="false"
sessionBackupTimeout="100"
copyCollectionsForSerialization="false"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
.....
</Context>
Among them, memcachedNodes used to configure the server IP address and Memcached server port (the default port: 11211), multiple Memcached services need to use a comma (, )to separate.
To ensure the high availability of iPortal, portal data storage can not use the built-in SQLite database, two iPortal services need to share the same MySQL database which support remote connection, then need to modify the% SuperMap iPortal_HOME% / webapps / iportal / WEB-INF / iportal. xml configuration file, you only need to comment out or delete SQLite database connection pool configuration information, the annotation symbol of MySQL database connection pool configuration information should be removed. The specific configuration is as follows:
<dbType>MYSQL</dbType>
<driverClass>org.mariadb.jdbc.Driver</driverClass>
<jdbcUrl>jdbc:mysql://192.168.120.40:3306/iportal323?useUnicode=true&characterEncoding=UTF-8</jdbcUrl>
<maxPoolSize>30</maxPoolSize>
<initialPoolSize>5</initialPoolSize>
<minPoolSize>5</minPoolSize>
<maxIdleTime>3000</maxIdleTime>
<maxWait>300000</maxWait>
<username>root</username>
<password>123</password>
Where the default "localhost" in the <jdbcUrl> node need to be changed to the IP address of the machine where the MySQL is located, and then the local login to MySQL, changes the "host" entry for the first record in the "user" table in the "mysql" database , From "localhost" to '%', restart MySQL. For more information about database configuration, see: Database Configuration.
To ensure the high availability of iPortal, user account information storage can not use the built-in SQLite database, two iPortal services need to share the same MySQL database which support remote connection. SuperMap iPortal 8C SP2 and later, support storing user account information in the MySQL database, and provides a visual configuration page. Start the iPortal service, log in to the iPortal portal as an administrator, select Manage -> Security -> Security Configuration -> Secure Information Store, switch the database type for storing user information from SQLite to MySQL, and iPortal automatically initialize the administrator Information (the administrator account created when the iPortal was first started) is synchronized to the MySQL database. The database used in the MySQL "service address" that needs to be entered must be a newly created empty database without any tables and can not be consistent with the MySQL database for the portal data store. For more information about user account information storage configuration, see: Security Information Store.
For the version before SuperMap iPortal 8C SP2, because the user account information is stored in the% SuperMap iPortal_HOME% / webapps / iportal / WEB-INF / iserver-security.db, it will not real-time synchronization updates in multiple iPortal, So it is recommended that you set all user account information before the iPortal service is online, and then overwrite iserver-security.db file of other iPortal with iserver-security.db with account information.
If you need to enable iPortal's server monitoring, you can not use the built-in SQLite database to ensure high availability, and two iPortal services need to share a MySQL database that supports remote connections. The configuration information of the database is in the iportal-monitor.xml configuration file in the installation directory (% SuperMap iPortal_HOME% \ webapps \ iportal \ WEB-INF). For details, see the database configuration.
The basic information of the monitored SuperMap iServer node is stored in the iportal-monitor.xml configuration file. The configured RabbitMQ information is stored in the rabbitmq.properties in the% SuperMap iPortal_HOME% \ webapps \ iportal \ WEB-INF \ config directory File, it is recommended that you add the monitored iServer node before the iPortal service is online, configure the RabbitMQ information, and then overwrite the other iPortal files with iportal-monitor.xml and rabbitmq.properties files.
To ensure the high availability of iPoral, the following files for two iPortal need to be manually synchronized:
Due to the different deployment scenarios, access to iPortal services is also different:
Case 1: Implementing iPortal High Availability Scenarios Based on Nginx
At this time the client can access the reverse proxy service address, for example: http: //192.168.120.40, in which, the default 80 port can be hidden, you can get the same with the original server content. The service root address will also become: http: //192.168.120.40 after registering the service agent, which also hides the service proxy port "8195".
In actual business applications, it is common to use the internal and external network to access the iPortal portal and map services. In this case, it is recommended that you map the ip of the Nginx reverse proxy server to a domain name and then access the iPortal service via the domain name, http: // www.iportal.com, at the same time, service root address will become: http: //www.iportal.com after the registration of service agent.
Case 2: Implementing Nginx High Availability Scenarios Based on Keepalived
At this point the client can access the Keepalived virtual IP address, for example: http: //192.168.120.136, in which, the default 80 port can be hidden, you can get the same with the original server content. The service root address will also become: http://192.168.120.136 after registering the service agent, thus hides the service proxy port "8195".
In actual business applications, it is common to use the internal and external network to access the iPortal portal and map services. In this case, it is recommended that you map the virtual ip of the Keepalived to a domain name and then access the iPortal service via the domain name, http: // www.iportal.com, at the same time, service root address will become: http: //www.iportal.com after the registration of service agent.