Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 69 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
69
Dung lượng
594,69 KB
Nội dung
Chapter 11 [ 595 ] Considering the pattern Portal-Group-Page-Content, the portal is implemented by portal instances. That is, the portal can manage multiple portal instances in one installation. And each portal instance can have many groups, which are implemented as organizations, communities, user groups, and users. Monitoring portal and portlets operations The portal provides abilities to monitor portlet and portal transactions. These abilities include, but not limited: • Average transaction times per portlet for each phase of the portlet life cycle • Minimum and maximum transaction times for each portlet transaction • Average times for portal requests, inclusive of all portlets • Minimum and maximum times for each portal request By the way, statistics were exposed via JMX MBeans. The portal also enables users to register MBeans from their own portlets. What is JMX ? JMX provides tools for managing and monitoring any Java applications network. Refer to http://java. sun.com/javase/technologies/core/mntr-mgmt/javamanagement. Setup The portal has specied the following properties for monitoring portal and portlet operations in portal.properties: monitoring.level.com.liferay.monitoring.Portal=HIGH monitoring.level.com.liferay.monitoring.Portlet=HIGH monitoring.portal.request=false monitoring.portlet.action.request=false monitoring.portlet.event.request=false monitoring.portlet.render.request=false monitoring.portlet.resource.request=false As shown in the preceding code, you can congure the appropriate level for monitoring Liferay. Valid values are: HIGH, LOW, MEDIUM, OFF. By default, monitoring on portal request and portlet action/event/render/resource request is disabled. Of course, you would be able to enable monitoring on portal request and portlet action/event/render/resource request by setting related properties to true in portal-ext.properties. Ongoing Admin Tasks [ 596 ] Database read-writer The portal provides capability to use one database cluster for read calls and another database cluster for write calls, called dynamic data source or database read-writer. The portal allows us to use two different data sources for reading and writing, enabling us to split database infrastructure into two sets: one optimized for reading and another optimized for writing. Setup Suppose there are two database servers, ${database.reader} and ${database. writer}, and both of them are clustered. Here we're going to use these two different data sources for reading and writing, that is, ${database.reader} for reading and ${database.writer} for writing. How do we achieve this? The following is an option to set up database read-writer connections: 1. First, congure two different dynamic data sources in portal-ext. properties, one for reading, and one for writing: jdbc.read.driverClassName=com.mysql.jdbc.Driver jdbc.read.url=jdbc:mysql://${database.reader}:3306/lfso?useUnicode =true&characterEncoding=UTF-8&useFastDateParsing=false jdbc.read.username=lportal jdbc.read.password=lportal jdbc.write.driverClassName=com.mysql.jdbc.Driver jdbc.write.url=jdbc:mysql://${database.write}:3306/lfso?useUnicode =true&characterEncoding=UTF-8&useFastDateParsing=false jdbc.write.username=lportal jdbc.write.password=lportal As shown in the preceding code, MySQL was used as an example only. You would denitely be able to use another database. The database name, port number, user name, and password should be adjusted to real values too. Ob- viously, you should use real database domain names or IPs for both ${data- base.reader} and ${database.writer}. 2. Then, enable dynamic data source conguration for the property spring. configs as follows in portal-ext.properties. spring.configs=\ # ignore details META-INF/audit-spring.xml,\ META-INF/dynamic-data-source-spring.xml,\ #META-INF/shard-data-source-spring.xml,\ META-INF/monitoring-spring.xml,\ Chapter 11 [ 597 ] \ META-INF/ext-spring.xml What's happening? As you can see, you can congure the portal to use one database cluster for read calls and another database cluster for write calls. The convention is to create a set of properties prexed with jdbc.read.* to handle read calls and another set of properties prexed with jdbc.write.* to handle write calls. These data sources can also be created via JNDI by setting the properties jdbc.read.jndi.name and jdbc. write.jndi.name. In fact, the portal has specied JDBC data sources, available for database read-writer in the dynamic-data-source-spring.xml le as follows: <bean id="liferayDataSource" class="org.springframework.jdbc. datasource.LazyConnectionDataSourceProxy"> <property name="targetDataSource"> <bean class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="targetSource" ref="dynamicDataSourceTargetSource" /> </bean> </property> </bean> <!—ignore details > As shown in the preceding code, JDBC data sources like "read" and "write" have been congured as "jdbc.read." and "jdbc.write." in the dynamic-data-source-spring. xml le. Database sharding As mentioned above, we have discussed database read-writer—dynamic data source. And moreover, all portal data from different portal instances is kept in the same database by default. In real cases, portal data from different portal instances should be kept in different databases. That's the reason we need database sharding in portal instances. What's database sharding? Let's have a look at a shared-nothing partitioning scheme—Database Sharding. Database Sharding is a shared-nothing partitioning scheme for large databases across a number of servers, enabling new levels of database performance and scalability. It provides a method for scalability across independent servers, each with their own CPU, memory, and disk. Refer to http://www.codefutures.com/ database-sharding. Ongoing Admin Tasks [ 598 ] In general, database sharding is a way of scaling your database horizontally. For a set of tables, you could split up the data, stored and fetched based on a given hash. In database sharding, one database doesn't get overloaded; there are smaller queries, as each table has less data now. You will get better overall throughput under load as all your IO isn't going through one database server. The portal supports database sharding for handling data across multiple portal instances. Setup Suppose there are three intranet websites such as Bookpub, BookpubStreet, and Bookpubworkshop in the enterprise "Palm Tree Publications". These are named as "bookpub.com", "bookpubstreet.com", and "bookpubworkshop.com" in a single server; where "bookpub.com" would be the web ID for default portal instance. These three websites should have their data set in three separated databases; there are no data shared among these websites. How do we achieve this? One approach is setting these websites as different portal instances with database sharding in a single server. The following is an option to achieve it: 1. First, set the default web ID as follows in portal-ext.properties. company.default.web.id=bookpub.com The default value of the property company.default.web.id was set as lif- eray.com in portal.properties. Note that Omni-admin users must be- long to the company with this web ID; and your default admin account will become "test@bookpub.com/test". 2. Second, prepare databases like book, bookstreet, and bookworkshop in portal-ext.properties. Note that you would have different database names, user names, and passwords with different database server IPs. jdbc.default.driverClassName=com.mysql.jdbc.Driver jdbc.default.url=jdbc:mysql://localhost/book?useUnicode=true&chara cterEncoding=UTF-8&useFastDateParsing=false jdbc.default.username=lportal jdbc.default.password=lportal jdbc.one.driverClassName=com.mysql.jdbc.Driver jdbc.one.url=jdbc:mysql://localhost:3306/bookstreet?useUnicode=tru e&characterEncoding=UTF-8&useFastDateParsing=false jdbc.one.username=lportal jdbc.one.password=lportal jdbc.two.driverClassName=com.mysql.jdbc.Driver jdbc.two.url=jdbc:mysql://localhost:3306/bookworkshop?useUnicode=t rue&characterEncoding=UTF-8&useFastDateParsing=false jdbc.two.username=lportal jdbc.two.password=lportal Chapter 11 [ 599 ] 3. Then enable database sharding by adding following lines in portal-ext. properties. shard.available.names=default,one,two shard.default.name=default shard.selector=com.liferay.portal.dao.shard. RoundRobinShardSelector The property shard.available.names species JDBC data sources, available for database sharding. These must be congured in the jdbc.* section above as well as in the shard-data-source-spring.xml le. The property shard. default.name sets the database that is to be used for the default company and globally used tables in a sharded environment. The property shard. selector species an algorithm for selecting a new shard on portal instance creation. Using the algorithm com.liferay.portal.dao.shard.RoundRob- inShardSelector, the portal will select from several different portal instanc- es and evenly distribute the data across them. Note that you can use com. liferay.portal.dao.shard.ManualShardSelector for shard selection via the web UI. 4. Finally, make sure the spring conguration is included in the portal-ext. properties as follows, which by default is commented out: spring.configs=\ # ignore details #META-INF/dynamic-data-source-spring.xml,\ META-INF/shard-data-source-spring.xml,\ # ignore details META-INF/ext-spring.xml The property spring.configs sets a list of comma delimited Spring congurations. These will be loaded after the bean denitions specied in the contextConfigLocation parameter in $PORTAL_ROOT_HOME/WEB-INF/web.xml. What's happening? Database Sharding is splitting up your database by various types of data that may be in it. It is a technique used for high scalability scenarios. When users log in, they are directed to the instance of the application that has their data in it. In fact, the portal has specied JDBC data sources that are available for database sharding in the shard-data-source-spring.xml le as follows: <bean id="liferayDataSource" class="org.springframework.jdbc. datasource.LazyConnectionDataSourceProxy"> <property name="targetDataSource"> Ongoing Admin Tasks [ 600 ] <bean class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="targetSource" ref="shardDataSourceTargetSource" /> </bean> </property> </bean> <!—ignore details > As shown in the preceding code, JDBC data sources such as "default", "one", and "two" have been congured as "jdbc.default.", "jdbc.one.", and "jdbc.two." in the shard-data-source-spring.xml le. Of course, you would be able to customize it according to your requirements. Suppose you want four shard data sources: default, one, two, and three. You're going to build four portal instances, where each portal instance has its own database. How do we implement it? The following is one option: 1. Create a folder named META-INF under the folder $PORTAL_ROOT_HOME/ WEB-INF/classes/. 2. Locate the JAR portal-impl.jar under the folder $PORTAL_ROOT_HOME/ WEB-INF/lib; and unzip all les under the folder META-INF to the folder $PORTAL_ROOT_HOME/WEB-INF/classes/META-INF. 3. Update following le according to your requirements for both non- clustered environment and clustered environment. shard-data-source-spring.xml 4. And nally do the related changes in the jdbc.* section and in the property shard.available.names. Portal administration The portal provides portal administrative functions. Thus we can not only access all organizations, roles, user groups, and users, but we can also manage portal version information and enterprise information such as organization name, ticker symbol, address, logo, current live sessions, authentication preferences, LDAP conguration and SSO integration, new user preferences, mail conguration, password policies, and more. We have discussed authentications in Chapter 3, Bringing in Users. In this section we're going to discuss password policies, enterprise information settings, and current live sessions. Chapter 11 [ 601 ] Password policies The portal implements enterprise password policies and user account lockout. As shown in the following screenshot, you can go to Portal | Password Policies under Control Panel and manage password policies. You can either search the password policies by inputting search keyword and clicking on the Search button, or add the password policies by clicking on the Add icon next to the icon View All. You can also either update permissions by clicking on the Permissions icon from the Actions button, or change members by clicking on the Assign Members icon from the Actions button. You can edit password policies by clicking on the Edit icon from the Actions button rst, and then you can change the settings of password policies as follows: You can use Changeable Settings as follows: • Changeable: Allow user to change his/her own password • Change Required: Require the user to change his password when the user rst logs in • Minimum Age: Determines how long a user must wait before changing their password again You can change Password Syntax Checking by enabling the checkbox Syntax Checking Enabled rst, and then conguring the following items: • Syntax Checking Enabled: Enable portal to check for certain words and length requirements • Allow Dictionary Words: Allow a dictionary word to be used as the password • Minimum Length: The minimum length of a password Ongoing Admin Tasks [ 602 ] You can also change Password History by enabling the checkbox History Enabled rst and then conguring the following items: • History Enabled: Enable tracking of password history, to prevent reuse of old passwords • History Count: The number of passwords to keep in the history Similarly, you can update Password Expiration by enabling the checkbox Expiration Enabled and conguring the following items: • Expiration Enabled: Enable passwords to expire after a specied time • Maximum Age: The maximum time that a password is valid, before it needs to be changed again • Warning Time: The time before a password expires, in which to warn the user of the upcoming password expiration • Grace Limit: The number of logins allowed after the password has already expired. To update User Account Lockout, you can click on the checkbox Lockout Enabled and then congure following items. • Lockout Enabled: Enable user accounts to get locked out after a specied number of failed logins • Maximum Failure: The maximum number of failed login attempts before the account is locked out • Reset Failure Count: The time before the "failed login count" is reset • Lockout Duration: The time that a user is locked out, preventing them from logging back in In a word, the portal provides ability to implement enterprise password policies and user account lockout. Password policies are managed internally from the portlet Enterprise Admin Password Policies (portlet ID 129). Note that everything here can be congured in portal-ext.properties as well. Assigning permissions There are two-level permissions related to Password Policies: permission on portlet and permissions on password policies. The following table shows permissions on the portlet. The role Community Member is set up with all the permissions (marked as 'X'): View, Conguration and Access in Control Panel, while the role Guest is set up with the permission action View. By default, the roles Community Member & Guest have permission action View (marked as '*'). Chapter 11 [ 603 ] Action Description Community Guest View Ability to view the portlet X, * X, * Conguration Ability to congure the portlet X Access in Control panel Ability to access the portlet in Control Panel X The following table shows permissions on password policies. The role Community Member is set up with the permissions (marked as 'X'): View, Delete, Permissions, Assign Members, and Update. Action Description Community Guest View Ability to view password policies X Delete Ability to delete password policies X Permissions Ability to assign permissions on password policies X Update Ability to update password policies X Assign Members Ability to assign members on password policies X What's happening? As you have seen, the Enterprise Password Policies portlet (portlet ID 129) gets displayed at the category Portal of Control Panel. Why? The portal has default settings for the Enterprise Admin Password Policies portlet as follows in $PORTAL_ ROOT_HOME/WEB-INF/liferay-portlet.xml. <portlet-url-class>com.liferay.portal.struts.StrutsActionPortletURL</ portlet-url-class> <control-panel-entry-category>portal</control-panel-entry-category> <control-panel-entry-weight>6.0</control-panel-entry-weight> The preceding code shows that the portlet Enterprise Password Policies will appear in the category Portal and position 6. And moreover, the portlet-url-class value extends com.liferay.portlet.PortletURLImplWrapper. Ongoing Admin Tasks [ 604 ] Portal settings You can update enterprise information under the Portal | Settings of Control Panel like general conguration, authentication, default user associations, reversed screen names, mail host names, email notications, addresses, phone numbers, additional email addresses, websites, display settings, and Google Apps. The following gure depicts the main tabs which can be used to change the enterprise information in details. As you can see, the portlet Enterprise Admin Settings provides capabilities to update enterprise information under the Portal | Settings of the Control Panel. Portal settings have been grouped into three sections at the right-side menu under the portal logo and portal name: Conguration, Identication, and Miscellaneous. Each section has a set of items as follows: The set of items within the Conguration section are as follows: • General: Including main conguration, navigation and additional information • Authentication: Including general authentication information, LDAP. CAS, NTLM, OpenID, Open SSO, Siteminder • Users: Covering Fields, Reserved Credentials and Default User Associations • Mail Host Names: Enter one mail host name per line for all additional mail host names • Email Notications: Covering Sender, Account Created Notication, and Password Changed Notication [...]... servlet filters by overriding them in portal- ext.properties: com .liferay. portal. servlet.filters.audit.AuditFilter=false com .liferay. portal. servlet.filters.sso.cas.CASFilter=false com .liferay. portal. servlet.filters.sso.ntlm.NtlmFilter=false com .liferay. portal. sharepoint.SharepointFilter=false com .liferay. portal. servlet.filters.virtualhost.VirtualHostFilter=false com .liferay. portal. servlet.filters.sso.opensso.OpenSSOFilter=false... field.editable.com .liferay. portal. model.User.screenName=user field.editable.com .liferay. portal. model.User.emailAddress=user As shown in the preceding code, you should be able to enable Organization status by setting field.enable.com .liferay. portal. model.Organization.status to true in portal- ext.properties The portal sets properties field.editable.com liferay. portal. model.User.screenName and field.editable.com .liferay portal. model.User.emailAddress... security for each cloud instance In brief, an enterprise can deploy Liferay Portal in Amazon EC2 so that the security settings for this portal server can be separated from the security of the enterprise' s own network This is particularly useful when the enterprise doesn't want to expose its own network to its partners or portal users Also, the Liferay Portal EC2 instances can be launched or terminated... D73CEB992A3BC5D77D4B181A670EA808 • User ID: such as 103 03 • Name: such as Lotti Stein • Email Address: such as lotti@bookpub.com • Last Request: such as 12/20/09 3: 06 PM • # of Hits: such as 5 • Browser/OS Type: such as Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1 .6) Gecko/20091201 Firefox/3.5 .6 GTB6 • Remote Host/IP: 127.0.0.1 / 127.0.0.1 • Accessed URLs: such as /portal/ layout?p_l_id =101 47?, and... Server has the following settings: IP: 192. 168 .2.170 Apache Tomcat Connector mod_jk 1.2 or above Apache JServ Protocol AJP 1.3 or above JDK 1 .6 or above Apache HTTP Server 2.2 or above Node1 has the following settings: IP: 192. 168 .2.171; Portal with Tomcat 6. x or JBoss 5.x.GA (or JBoss 4.2.3.GA) Node2 has the following settings: IP: 192. 168 .2.172; Portal with Tomcat 6. x or JBoss 5.x.GA (or JBoss 4.2.3.GA)... have seen, the Enterprise Admin Settings portlet (portlet ID 130) got displayed at the category Portal of Control Panel Why? The portal has default settings for the Enterprise Admin Settings portlet as follows in $PORTAL_ ROOT_HOME/ WEB-INF /liferay- portlet.xml portal 7.0 [ 60 7 ] Ongoing... server: 2 x Intel Core 2 Quad E5430 2 .66 GHz CPU, 12MB L2 cache (8 cores total), 8GB memory, 2 x 146GB 10k RPM SCSI, CentOS 5.2 64 -bit Linux The portal' s CMS/WCM scales to beyond 150,000 concurrent users on a single Portal server with average transaction times under 50ms and 35% CPU utilization Given sufficient database resources and efficient load balancing, the portal can scale linearly as one adds... above code, the portal sets the default locale like country as US and language as en The portal also sets the default time zone as UTC Of course, you can override the above properties in system-ext.properties [ 61 1 ] Ongoing Admin Tasks In addition, the portal has configured following properties in portal. properties: google.apps.username= google.apps.password= As shown in the above code, the portal sets... memory (that is, more than 8 GB), you could increase JVM parameters settings like this: -Xms4096m –Xmx4096m -XX:MaxPermSize =102 4m -Xms6144m –Xmx6144m -XX:MaxPermSize =102 4m In addition, garbage collection can become a bottleneck depending on the requirements of the portals By understanding the requirements of the portal and the garbage collection options, it is possible to minimize the impact of garbage... true in portal- ext.properties to ensure that a user is synchronized with the default associations of groups, roles, and user groups upon every login [ 60 9 ] Ongoing Admin Tasks By the way, the portal has specified the following properties related to both Users and Organizations when they are created: field.enable.com .liferay. portal. model.Organization.status=false field.editable.com .liferay. portal. model.User.screenName=user . field.enable.com .liferay. portal. model.Organization.status to true in portal- ext.properties. The portal sets properties field.editable.com. liferay. portal. model.User.screenName and field.editable.com .liferay. portal. model.User.emailAddress. http://java. sun.com/javase/technologies/core/mntr-mgmt/javamanagement. Setup The portal has specied the following properties for monitoring portal and portlet operations in portal. properties: monitoring.level.com .liferay. monitoring .Portal= HIGH monitoring.level.com .liferay. monitoring.Portlet=HIGH monitoring .portal. request=false monitoring.portlet.action.request=false monitoring.portlet.event.request=false monitoring.portlet.render.request=false monitoring.portlet.resource.request=false As. are created: field.enable.com .liferay. portal. model.Organization.status=false field.editable.com .liferay. portal. model.User.screenName=user field.editable.com .liferay. portal. model.User.emailAddress=user As