Showing posts with label Zookeeper. Show all posts
Showing posts with label Zookeeper. Show all posts

Tuesday, April 23, 2013

Apache Solr 4 Cook Book Review

Book Review : Apache Solr 4 Cookbook Review
Author: Rafal Kuc
Reviewed by : Harish Ganesan and Vijay Olety
Book URL : http://www.packtpub.com/apache-solr-4-cookbook/book

Comments : 

I recently read this book and i am really impressed! This book provides good understanding of Apache Solr for both developers as well as consultants.
The book starts off well with an introduction to Apache Solr, the web / app servers required, the role of Zookeeper, why clustering your data is vital ?, the various directory implementations, performance-oriented caching mechanisms, a sample crawler module which coupled with Solr gives a complete end-to-end solution, the role of Apache Tika as a extracting toolkit and the ease of customizing Solr. From then on, the book dwells into the details.
The first step is indexing. It plays a vital part in the entire search solution. Data can be in the form on .txt, .pdf or any other format. It is imperative that all such formats are easily indexable. One of the widely used tools for extracting metadata and language detection is Apache Tika. Data can also be present in a database, for which the Data Import Handler is handy. It comes in two variants – full and delta. Every detail is nicely explained with examples which can make the development time faster. DIH also helps us to modify the data while importing which I felt is a pretty neat feature! One of the nicest features included in Solr 4 is the ability to update single field in a document. I am not sure why this was included in the earlier versions but it’s a classic case of better late than never.
The next step in the pipeline is the data analysis which is achieved through the use of analyzers and tokenizers. Various use cases include elimination HTML and XML tags, copying the contents of one field to another and stemming words amongst others. The detailing that has gone into explaining every concept, the examples and the associated step-by-step explanation is really helpful.
Now that the data is indexed and the data preparation is completed, it’s time to query Apache Solr! Searches can be performed on individual words or on a phrase. You can boost or elevate certain documents over others based on your requirements. Simple concepts such as sorting and faceting of results to complex ones such as ignoring typos using n-grams and detecting duplicates are very simple to understand and perform. Faceting, in particular, is gaining momentum as it helps in implementing the auto-suggest feature and narrowing down the search criteria. A newly introduced feature called the pivot faceting was a much needed one and it vastly simplifies certain use cases related to faceting. Solr provides immense capabilities when it comes to querying and this book explains each of them in great detail taking real-world examples.
We indexed and queried the data. But as our application scales, we have to get our hands dirty and start fine-tuning the performance metrics in order to give a good user experience to our customers. This is where caches and its various flavors and granularities starts to make sense. Cache always plays a major role in any deployment and it is necessary to monitor Solr at all times to gauge its performance. This book can done a great job in clearly explaining the various types of caches, the commit operation and its impact on searchers and how to overcome these. This topic is really important for any Solr real-world deployment and this book has not let me down!
Apache Solr 4.0 introduced the most-awaited SolrCloud feature that allows us to use distributed indexing and searching. Setting up of SolrCloud cluster along with a Zookeeper ensemble to enable replication, fault-tolerance and high availability along with disaster recovery is a piece-of-a-cake now. I really appreciate the time and effort spent on documenting and explaining how to set up two collections inside a single cluster. It was a nightmare to find information on this particular topic when we implementing SolrCloud for one of our customers. But I am rest assured that others referring this book will save precious time of theirs. Adding / deleting nodes from a cluster is no longer a tedious task as the entire process is automated through the presence of Zookeeper nodes. The in-depth knowledge of the author in these topics is clearly visible and is of great help to all the readers. A touch on Zookeeper Rolling Restart, though off-topic, might enable readers to get a complete birds-eye view of the entire cluster. Certain features such as soft commit and NRT search have been explained in detail afterwards (under Real-life Situations) but I felt that at least a mention earlier on would have provided a much needed continuity in that section. For the geeky readers like me, a detailed description about load balancing across shards and replicas and their customizations, if any, would have added an extra amount of spice to this well-cooked food!
As with any other tool, Solr deployment too will run into some kind of a problem. This section details the common problems that are encountered and effective ways to overcome these. Shrinking the size of the index and allocating enough memory in advance amongst others are some of the solutions explained in detail and is clearly documented in this book.
Lastly, as every developer would have wanted it, the real-world scenarios are described and the various Solr concepts that were explained in earlier sections are put together as part of a complete end-to-end solution.
Any one trying Solr 4.0 must read this book in its entirety before recommending a Solr production architecture. As mentioned above, there are a few suggestions which if incorporated in this book would benefit readers. All in all, this book will be really helpful for the developers and consultants alike!


Thursday, March 14, 2013

Configuring Apache SolrCloud on Amazon VPC


We are going to construct an Apache SolrCloud (4.1) with 12 node EC2 instance(s) inside Amazon VPC in this post.  Since the search data stored inside the SolrCloud is critical, we are going to build High availability at Solr Node level as well as AZ level. This setup will be done inside private subnet of Amazon VPC and will leverage 3 Availability Zones of the Amazon EC2 Region.

To get an intro about the SolrCloud and its components, Refer article: http://harish11g.blogspot.in/2013/03/Introduction-Apache-Solrcloud-on-Amazon-EC2-AWS.html


Deployment architecture of the setup is given below:


A small brief about setup:
  • 3 Zookeepers will be deployed on 3 Availability Zones. ZK EC2 instances will be deployed on the Private subnet of the Amazon VPC.
  • 3 Solr Shard EC2 instances will be deployed on Private subnet of Availability Zone 1 inside Amazon VPC.
  • 3 Solr Replica EC2 instances will be deployed on Private subnet of Availability Zone 2 inside Amazon VPC.
  • 3 Solr Replica EC2 instances will be deployed on Private subnet of Availability Zone 3 inside Amazon VPC.
  • EBS optimized + PIOPS EC2 instances can be used for Solr EC2 Nodes



To know more about SolrCloud Deployment best practices on Amazon VPC, Refer article:  http://harish11g.blogspot.in/2013/03/Apache-Solr-cloud-on-Amazon-EC2-AWS-VPC-implementation-deployment.html


Step 1: Creating Virtual Private Cloud on AWS
Create a VPC with Public and Private Subnets. Assume the Load balancer and Web/App Servers can reside on the public subnet and Apache Solr Cloud will reside on the private subnet of the VPC.


Step 2: Assigning the IP for the Subnets
Create the subnet with its IP range. Chose the Availability zone for this subnet.



Step 3: Multiple Subnets on Multiple AZ’s
Create multiple subnets in Multiple AZ for building a Highly available setup for SolCloud




Step 4: Install Java for Zookeeper & Solr
Amazon Linux is chosen as the EC2 OS variant. Execute the following instructions on the respective EC2 nodes after their launch.  EC2 instances should be launched in Multi-AZ in Multiple VPC Private Subnets.
Solr uses Zookeeper as the cluster configuration and coordinator. Zookeeper is a distributed file system containing information about all the Solr Nodes. Solrconfig.xml, Schema.xml etc are stored in the repository.We have used Oracle-Sun Java over OpenJDK

“sudo -s”
“cd /opt”
“wget --no-cookies --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2Ftechnetwork%2Fjava%2Fjavase%2Fdownloads%2Fjdk-7u3-download-1501626.html;" http://download.oracle.com/otn-pub/java/jdk/7u13-b20/jdk-7u13-linux-x64.rpm”
“mv jdk-7u10-linux-x64.rpm?AuthParam=1357217677_76ec3d8d9a3644f4b9ec1ea79e1fcf33 jdk-7u10-linux-x64.rpm  jdk-7u10-linux-x64.rpm”
“sudo rpm -ivh jdk-7u10-linux-x64.rpm”
“alternatives --install /usr/bin/java java /usr/java/jdk1.7.0_10/jre/bin/java 20000”
“alternatives --install /usr/bin/javaws javaws /usr/java/jdk1.7.0_10/jre/bin/javaws 20000”
“alternatives --install /usr/bin/javac javac /usr/java/jdk1.7.0_10/bin/javac 20000”
“alternatives --install /usr/bin/jar jar /usr/java/jdk1.7.0_10/bin/jar 20000”
“alternatives --install /usr/bin/java java /usr/java/jre1.7.0_10/bin/java 20000”
“alternatives --install /usr/bin/javaws javaws /usr/java/jre1.7.0_10/bin/javaws 20000”
“alternatives --configure java”

Add JAVA_HOME in .bash_profile:
“vim ~/.bash_profile”
                export JAVA_HOME="/usr/java/jdk1.7.0_09"
                export PATH=$PATH:$JAVA_HOME/bin
Restart the instance.
“init 6”
Check the version of Java installed using “java -version” command




Step 5: Configure the ZooKeeper (v3.4.5) Ensemble:
Since single Zookeeper is not ideal for a large Solr cluster (because of SPOF), it is recommended to configure multiple Zookeepers in concert as an ensemble .In this step we will install and configure 3 ZooKeeper EC2 nodes spanning across 3 different Availability Zones in respective Private Subnets inside a VPC.Zookeeper will be configured on Amazon Linux.

“sudo yum update”
“sudo -s”
“ cd /opt”
“tar -xzvf zookeeper-3.4.5.tar.gz”
“rm zookeeper-3.4.5.tar.gz”
“cd zookeeper-3.4.5”
“cp conf/zoo_sample.cfg conf/zoo.cfg”

Add the following lines in zoo.cfg

“vim conf/zoo.cfg”
            dataDir=/data
                server.1=[zk-server01-ip]:2888:3888
                server.2=[zk-server02-ip]:2888:3888
                server.3=[zk-server03-ip]:2888:3888
“cd /opt/zookeeper/data”
“vim myid”
                1 or 2 or 3 respectively on each ZooKeeper EC2 instances in Multi-AZ

#Starting ZooKeeper Program.
“bin/zkServer.sh start”


  • Follow the above steps in all the ZooKeeper servers. Refer Clustered (Multi-Server) Setupand Configuration Parameters for understanding quorum_port, leader_election_port and the file myid.
  • Every ZooKeeper node needs to know about every other ZK EC2 node in the ensemble, and a majority of EC2’s (called a Quorum) are needed to provide the service. Make sure the VPC IP of all the Zookeepers are given in every ZK node, like the one in following command.
    • server.1=<ip>:<quorum_port>:<leader_election_port>
    • server.2=<ip>:<quorum_port>:<leader_election_port>
    • server.3=<ip>:<quorum_port>:<leader_election_port>



Step 6: Configuring Solr 4.1 EC2 node
In this step we will install and configure 3 Apache Solr4.1 Shard EC2 instances in a single Amazon AZ and 2 Solr Replicas in another AZ in their respective Private subnets. Please note that we have to specify all the ZooKeeper (ZK) hosts on every Solr instance as below.
Note: Solr gets comes with jetty in default, it is suggested to use tomcat for production nodes.
Perform the following after launching EC2 instances in Multi-AZ in Multiple VPC Private Subnets.

“sudo -s”
“yum update”
“cd /opt”
“wget http://apache.techartifact.com/mirror/lucene/solr/4.1.0/apache-solr-4.1.0.tgz”
“tar -xzvf apache-solr-4.1.0.tgz”
“rm -f apache-solr-4.1.0.tgz”

On Solr Shard/Replica Instances:

“cd /opt/apache-solr-4.0.0/example/”
“vim /opt/apache-solr-4.0.0/example/solr/collection1/conf/solrconfig.xml”
Change <dataDir>/var/data/solr</dataDir> to <dataDir>/data</dataDir>

Starting Solr4.1 Shard/Replica Java Program.
“java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=SolrCloud4.1-Conf -DnumShards=3 -DzkHost=[zk-server01-ip]:2181,[zk-server02-ip]:2181,[zk-server03-ip]:2181 -jar start.jar

“java -DzkHost= DzkHost=<server1_ip>:<client_port>,<server2_ip>:<client_port>,<server3_ip>:<client_port> -jar start.jar”



  • -DnumShards: the number of shards that will be present. Note that once set, this number cannot be increased or decreased without re-indexing the entire data set. (Dynamically changing the number of shards is part of the Solr roadmap!)
  • -DzkHost: a comma-separated list of ZooKeeper servers.
  • -Dbootstrap_confdir, -Dcollection.configName: these parameters are specified only when starting up the first Solr instance. This will enable the transfer of configuration files to ZooKeeper. Subsequent Solr instances need to just point to the ZooKeeper ensemble.
  • The above command with –DnumShards=3 specifies that it is a 3-shard cluster. The first Solr EC2 node automatically becomes shard1 and the second Solr EC2 node automatically becomes shard2 …. What happens when we launch fourth Solr instance in this cluster?  Since it’s a 3-shard cluster, the fourth Solr EC2 node automatically becomes a replica of shard1 and the fifth Solr EC2 node becomes a replica of shard2.

Step 7: AWS Security Group TCP Ports to be enabled:

Configure the following TCP ports on the AWS security group to allow access between Solr and ZK nodes deployed in Multiple AZ.
  • Solr Shards/Replicas will connect to ZK through TCP Port 2181
  • Solr Web Interface with Jetty container through TCP Port 8983
  • Solr Web Interface with Tomcat container through TCP Port 8080
  • Every instance that is part of the ZooKeeper ensemble should know about every other machine in the ensemble. We can accomplish this with the series of lines of the form server.id=host:port:port For example,
    • server.1=[vpc-ip]:2888:3888
    • server.2=[vpc-ip]:2888:3888
    • server.3=[vpc-ip]:2888:3888
  • TCP Ports 2888, 3888 should be opened for ZK Ensemble.
This article was co-authored with ramprasad. His linkedin handle in.linkedin.com/in/ramprasadguru


Related Articles:

Tuesday, March 5, 2013

Apache SolrCloud Implementation on Amazon VPC


Recently i architected a 13+ EC2 Node(s) SolrCloud Shard built in with HA and scalability inside Amazon Virtual Private Cloud. Since the base product engineered had both on-premise and SAAS edition, we were unfortunately not able to use Amazon CloudSearch as it may cause AWS dependency in this case in product tech stack.  This Solr architecture was secured using Amazon VPC, Private subnets, Access controls, AWS Security groups and IAM. The SolrCloud cluster was designed to accommodate index data in memory and some search data overflowing to EBS disk. The Cluster was designed to handle ~100 GB of distributed index data and another 200+ GB of Search data on EBS disks.  The Web/App tier, Business and Back ground tier will access the SolrCloud deployed in private subnet.   In this post I will be sharing my experience, learning, best practice and tips on architecting SolrCloud on AWS platform.



In the above architecture SolrCloud is configured on Amazon Virtual Private Cloud (VPC) in Amazon EC2 region: USA-EAST.  Let us explore the diagram in detail.

To know more about components of SolrCloud please refer my earlier post:

Zookeeper (ZK) for SolrCloud Best Practices:
  • Though Zookeeper comes embedded with Solr in default package, i recommend to run Zookeepers in separate EC2 instances in production setups.
  • Since Zookeeper EC2 maintains the cluster information either m1.small/medium is enough for most of the setups for ZK nodes. For heavily used setups we can start with m1.large for the Zookeeper EC2 nodes. We used m1.large for ZK nodes.
  • Single Zookeeper EC2 node is not ideal for a production setups (or) large Solr clusters because of SPOF, it is recommended to configure Zookeepers in concert as an ensemble comprising of at least 3 ZK EC2 nodes starting with.  Every ZooKeeper EC2 node needs to know about every other ZooKeeper EC2 node in the ensemble, and a majority of ZK EC2’s (called a Quorum) are needed to provide search service. For example, in a ZooKeeper ensemble of 3 ZK EC2’s if anyone of them fails, the cluster will be performing with the remaining 2 ZK EC2 nodes (constituting a majority). In case more than 1 ZK nodes can fail, then a 5 EC2 node ZooKeeper setup is  needed to allow for the failure of up to 2 EC2 ZK at a time.
  • In an event the ensemble loses the majority, then reads can be performed from the Solr cluster as usual but the writes will be restricted. We need to get enough number of ZK EC2 up and running for the majority number to be satisfied.
  • Amazon EC2 regions are further sub divided into Availability Zones.  In some Amazon EC2 regions there are only 2 availability zones. In such Amazon EC2 regions it becomes little complex to design the ensemble with optimum number of Zookeeper EC2 instances for HA. Imagine if we split and deploy 3:2 ZK nodes in two availability zones in that Amazon EC2 region, and all ZK EC2 becomes non-responsive in AZ  1a where we have deployed 3 ZK EC2’s, then the quorum loses the majority and cluster becomes read only. There is a chance of intermittent search service failure even though we had designed the cluster with 5 ZK nodes.  This cannot be avoided in such specific Amazon EC2 regions and in event ZK nodes go down we need to get them up in another available AZ.  Luckily for us it was US-East, need to crack a solution for other Amazon EC2 regions. More ZK is always better.
  • In Amazon VPC, I would recommend 3 private subnets in 3 AZ. Deploy the ZK nodes in 3 AZ inside these subnets. Assign VPC internal IP for the same. Enable ZK Peer discovery + ZK discovery by Solr nodes though this VPC internal IP.
  • If you want minimize the recovery time objective in event of ZK failures in AWS NON-VPC cloud, I would recommend having Amazon Elastic IP assigned for the Zookeeper nodes and enabling ZK Peer discovery + ZK discovery by Solr nodes though this Amazon Elastic IP.
  • Since all the ZK EC2 instances communicate with each other and exchange the data constantly, it is recommended to use S3 backed AMI(s) with ephemeral disks for the Zookeeper tier. EBS disks at this tier will add up to unnecessary costs and most cases not needed in this tier.
  • Modifying the running Zookeeper ensemble is not an easy task. So depending upon the HA levels needed i would recommend starting the ZK ensemble with 3/5/7/11 etc nodes. Currently the ZK ensemble number modification is in the Solr roadmap. Current workaround for this problem is to do a rolling restart of Zookeepers. Refer blog Rolling Restart


SolrCloud Shards & Replica’s Implementation practices:
  • Solr comes with Jetty engine; replace this with Stable Tomcat release for production setups.
  • Since the number of Shards cannot be modified on a running SolrCloud cluster it is advised to do proper capacity planning before designing the cluster. Changing the number of shards (ideally increasing) is a pattern that is observed on many growing websites, but sadly, it looks like it is only in the roadmap of Solr.
  • It is recommended to keep the shards and replica nodes in separate Availability zones inside an Amazon EC2 region.  Response latency and Inter region Cost (AZ transfer cost) are the negatives, but this architecture will provide you with better High Availability.
  • No need to Crisscross the Shards and Replicas between AZ, follow the above deployment pattern illustrated in the diagram, it will be easy for maintenance on long term.
  • SolrCloud is configured in the private subnet of the Amazon VPC and access controls are opened for the Web/App residing the public/private subnet to access the SolrCloud search service.
  • Three Availability zones are used US-EAST 1a/1b/1c for this setup and 3 subnets are in respective AZ’s.
  • Access between the subnets residing is different AZ’s are opened.
  • Zookeeper EC2 nodes are installed in all 3 Availability zones inside the subnet ranges (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24)
  • Zookeepers EC2 nodes are made aware of the other ZK nodes in the ensemble using the VPC IP’s.
  • 3 Solr Shards are deployed in US-East-1a in subnet range 10.0.1.0/24. Replica Set 1A/1B/1C are deployed in US-EAST-1B and Replica Set 2A/2B/2C are deployed on US-EAST-1C. 
  • Note: 3rd shard & replica are not illustrated on the diagram for cosmetic purposes


To know more about Configuring SolrCloud on Amazon VPC, Refer article:  
http://harish11g.blogspot.in/2013/03/Configuring-installing-Apache-Solrcloud-solr4.x-on-Amazon-VPC-EC2-AWS.html



High availability:
  • In event “Shard leader A” EC2 becomes non responsive in US-EAST-1A, the Replica Set 1A or 2A in any of the availability zones will be automatically be elevated to become the new Shard leader
  • In event “Replica node 1A” EC2 becomes non responsive in US-EAST-1B, the Shard leader and other replica node is still active to take the requests
  • In event all the EC2 nodes in US-EAST-1A becomes non responsive (AZ level outage) , the replica Set either in AZ 1B or 1C will be automatically be elevated to become new Leaders and they will take the requests
  • Every Apache Solr Node is made aware of the entire ZK ensemble addresses. All the cluster configuration and coordination will be done by ZK. In event of Apache Solr Node failure and new Solr nodes are brought into the cluster, they will contact the ZK and take their respective roles (shards, leaders, replicas etc).
  • Note: Non responsive EC2 nodes should be monitored actively and new healthy nodes should be replaced in event of failure to maintain the optimum performance levels

Scalability:
  • Search requests will be scaled out and be handled by shard leaders or any of the replica nodes in the cluster
  • For more read Scalability more replicas with better instance type can be added into the architecture
  • Write requests will be handled only by the Shard leaders first, hence for write scaling/load distribution we have employed sharding in place. This way the write requests are distributed between the shards.             
  • Growing Indexes can be scaled Up/Out and distributed using the Sharding architecture of Solr

Monitoring:
  • All stats were integrated with Amazon CloudWatch on Custom metrics. Custom scripts were developed.
  • Service level monitoring was done using Nagios.

Storage:
  • Provisioned IOPS with EBS optimized Instances was used. This was particularly useful and provided consistent performance when disk was accessed for search data
  • RAID 0 EBS Striping for better IO performance. (On the Implementation Road Map)
  • IO testing using Sysbench

Backups & Recovery:
  • Periodic EBS snapshots
  • Periodic Full Solr Dumps

Deployment:
  • Automated deployment using Opscode Chef 10.X for Apache Solr + entire setup


On Road map:
  • RAID 0 EBS Striping for better IO performance
  • TrendMicro Secure Cloud for Disk encryption. 

Though Apache SolrCloud has lots of improvements in the HA, Replication, Distribution and Sharding front, we had some difficulties while planning for future expansion. Some of them are:

  • Number of ZK nodes has to be fixed at cluster creation time, it is not a major problem and there are workarounds.
  • Number of Shards has to be fixed at cluster creation time, This is a major problem for applications whose search data is growing rapidly. At some point they will exceed the provisioned shard capacity will need to add new shard and re-balance the entire cluster. This is currently a complex exercise and i hope SolrCloud team will solve this problem soon. This is one area where Amazon cloudSearch has done excellent automation and eased this for the customers. You can keep expanding the nodes for Scalability and HA seamlessly in Amazon CloudSearch.


Apache SolrCloud on Amazon EC2 FAQ:

  1. How are the Solr replicas assigned to shards?
    1. When a new Solr server is added, it is assigned to the shard with the fewest replicas, tie-breaking on the lowest shard number.
  2. Why should I specify all the ZooKeepers for the parameter –DzkHost?
    1. TCP connections are established between the Solr instance and the ZooKeeper servers. When a ZooKeeper server goes down, the corresponding TCP connection is lost. However, other existing TCP connections are still functional and hence this ensures fault tolerance of the SolrCloud cluster even when one or more ZooKeeper servers are down.
  3. What is a Solr transaction log?
    1. It is an append-only log of write operations maintained by each node. It records all write operations performed on an index between two commits. Anytime the indexing process is interrupted, any uncommitted updates can be replayed from the transaction log.
  4. When does the old-style replication kick in?
    1. When a Solr machine is added to the cluster as a replica, it needs to get itself synchronized with the concerned shard. If more than 100 updates are present, then an old-style master-slave replication kicks off. Otherwise, transaction log is replayed to synchronize the replica.
  5. How is load balancing performed on the Solr client side?
    1. Solr client uses LBHttpSolrServer. It is a simple round-robin implementation. Please note that this should NOT be used for indexing.
  6. What will happen if the entire ZooKeeper ensemble goes down or quorum is not maintained?
    1. ZooKeeper periodically sends the current cluster configuration information to all the SolrCloud instances. When a search request needs to be performed, the Solr instance reads the current cluster information from its local cache and executes the query. Hence, search requests need not have the ZooKeeper ensemble running. Please bear in mind that any new instances that are added to the cluster will not be visible to the other instances.
    2. However, a write index request is a bit more complicated. An index write operation results in a new Lucene segment getting added or existing Lucene segments getting merged. This information has to be sent to ZooKeeper. Each Solr server must report to ZooKeeper which cores it has installed. Each host file is of the form host_version. It is the responsibility of each Solr host/server to match the state of the cores_Nfile. Meaning, each Solr server must install the cores defined for it and after successful install, write the hosts file out to ZooKeeper. Hence, an index write operation always needs ZooKeeper ensemble to be running.
  7. Can the ZooKeeper cluster be dynamically changed?
    1. ZooKeeper cluster is not easily changed dynamically but is part of their roadmap. A workaround is to do a Rolling Restart.
  8. Is there a way to find out which Solr instance is a leader and which one is a replica?
    1. Solr 4.0 Admin console shows these roles in a nice graphical manner.
  9. How much time does it take to add a new replica to a shard?
    1. For a shard leader index size of 500MB, an m1.medium EC2 cold-start replica instance takes about 30 seconds to synchronize its index with the leader and become part of the cluster.
  10. Is it possible to ensure that the SolrCloud cluster is HA even when an entire AZ goes out of action?
    1. When an entire AZ is down and the cluster is expected to be running successfully, the simplest and recommended approach is to have all leaders in one AZ and replicas in other AZs with the ZooKeeper ensemble spanning across AZs.



Thanks Vijay, Ramprasad and Dwarak for their support during this exercise.




Sunday, March 3, 2013

Introduction to Apache SolrCloud on AWS


In this post we are going to explore SolrCloud (version 4.X) on AWS. In my previous articles on Solr(3.x)+AWS we saw a glimpse of how complex it is to partition and scale out Solr nodes. Latest version of SolrCloud was designed from ground up addressing these architectural needs for cloud based implementations.  SolrCloud comes with highly available, fault tolerant cluster architecture built in with distributed indexing and search capabilities.

Components of Apache SolrCloud
SolrCloud consists of following architectural components as mentioned in the below diagram:



Zookeeper:  Solr uses Zookeeper as the cluster configuration and coordinator. Zookeeper is a distributed file system containing information about all the Solr Nodes. Solrconfig.xml, Schema.xml etc are stored in the repository. 
  • Though Zookeeper comes embedded with Solr in default package, It is recommended to run Zookeepers in separate EC2 instances in production setups.
  • Since Zookeeper EC2 maintain the cluster information either m1.small/medium is enough for most of the setups. For heavily used setups we can start with m1.large for the Zookeeper.  
  • Single Zookeeper is not ideal for a large Solr clusters because of SPOF, it is recommended to configure Zookeepers in concert as an ensemble comprising of at least 3 EC2 nodes starting with.  Every ZooKeeper server needs to know about every other ZooKeeper server in the ensemble, and a majority of EC2’s (called a Quorum) are needed to provide service. For example, in a ZooKeeper ensemble of 3 EC2’s if anyone of them fails, the cluster will be performing with the remaining 2 ZK EC2 nodes (constituting a majority). In case more than 1 ZK nodes can fail, then a 5 EC2 node ZooKeeper setup is  needed to allow for the failure of up to 2 EC2 ZK at a time.
  • In an event the ensemble loses the majority, then reads can be performed from the Solr cluster as usual but the writes will be restricted. We need to get ZK EC2 up and running for the majority number to be satisfied.
  • Amazon EC2 regions are further sub divided into Availability Zones.  In some Amazon EC2 regions there are only 2 availability zones. In such EC2 regions it becomes little complex to design the number of Zookeeper EC2 instances for HA. Imagine if we split 3:2 in two availability zones in an Amazon EC2 region, and all ZK EC2 becomes non-responsive in Zone 1a where we have deployed 3 ZK EC2’s, then the quorum loses the majority and cluster becomes read only.
  • Since all the ZK EC2 instances communicate with each other and exchange the data constantly, it is recommended to use S3 backed AMI with ephemeral disks itself for the Zookeeper tier.
  • Modifying the Zookeeper ensemble once started is not easy. So depending upon the HA levels you want i would recommend starting the ZK ensemble with 3/5/7/11 etc nodes. Currently the ZK ensemble modifcation is in the Solr roadmap. Current workaround for this problem is to do a rolling restart of Zookeepers. (Rolling Restart article)
  • If you want minimize the recovery time objective in event of ZK failures, I would recommend having Amazon Elastic IP assigned for the Zookeeper nodes and enabling ZK Peer discovery + ZK discovery by Solr nodes though this Amazon Elastic IP. In Amazon VPC, if the Solr cluster is going to reside inside the private subnet then VPC IP is enough for the ZK EC2 instances.

Shards & Replica’s: Solr indexes can be partitioned across multiple Solr EC2 nodes called as Shards. Index data present in every shard can be replicated into one or more Replica Node(s).  Configuring a Multi shard + Replica architecture in Amazon EC2 is made easy compared to the previous version of Apache Solr. Specify the number of Shards required in the setup with “-DnumShards” parameter, Add the Solr EC2 nodes they will automatically added into the Shard architecture. Example:  if you start the cluster with “–DnumShards=2” it means that you are building a 2-shard cluster. The first Solr EC2 instance automatically becomes “shard1” and the second Solr EC2 you launch will automatically attached as “shard2” in the architecture. What happens when you add a third & fourth Solr EC2 instances into the cluster? Since it’s a 2-shard cluster, the third Solr EC2 automatically becomes a replica of shard1 and the fourth Solr EC2 becomes a replica of shard2. You now have 4-node (2-shard 2-replica) Solr cluster running on AWS. The first Solr EC2 node that usually becomes “shard1” is assigned the role of a Leader for that shard group; all subsequent Solr EC2 nodes that join the same “shard1” group will become replica nodes. All writes will happen on the Leader and the same will be pushed to the replicas. If the Leader Node goes down, Solr does automatic fail over and one of the replicas will be promoted as the new leader node.




To know more about Configuring SolrCloud on Amazon VPC, Refer article:  
http://harish11g.blogspot.in/2013/03/Configuring-installing-Apache-Solrcloud-solr4.x-on-Amazon-VPC-EC2-AWS.html



How documents are indexed in SolrCloud?

The document indexing process in the SolrCloud works as follows:
Step 1: If an index document request is sent to a Shard leader node, then the leader node first checks if the document belongs to the same shard group. If document belongs to this shard group then it will be written to the transaction log of the shard EC2 node.  On the contrary, if the document belongs to another shard group, then it will be automatically forwarded to the leader of the respective shard group, which in turn writes to its transaction logs.
Step 2: Shard Leader EC2 node transfers the delta of the transaction log to all its replica nodes. The replica nodes in turn update their respective transaction logs and send an acknowledgement to the leader node.  Once the leader node receives acknowledgements that all the replica node(s) have received the updates, the original index request is responded back.
Step 3: If an index document request is sent to a replica node, then the same is forwarded to the leader node in that shard.

How search is performed in SolrCloud ?

The distributed search is completely easy in SolrCloud, you need not worry about the number of shards/replicas/ZK, which one to query? What happens when one of them is down?
A query request may be sent to one of the Solr EC2 nodes (either a leader or a replica), Solr internally load balances the requests across replicas to process the response. If the “shards.tolerant” parameter is set to “true” then SolrCloud can continue to serve results without any interruption as long as at least one Solr node hosts every shard data.  This property returns the search result with the documents that are available and avoids 503 error responses in event of any node is down.

Some interesting features in Apache SolrCloud

Soft Commit: A hard commit calls fsync on the index files to ensure that they have been flushed to stable storage and no data loss will result from a power failure. It is an expensive operation as it involves disk IO. Soft commit feature introduced in Solr 4.X to handle NRT search, is much faster as it only makes the index change visible to the searchers but does not call fsync. This is accomplished by writing the changes to the transaction log. Think of it as adding documents to an in-memory writeable segment. As the size of the transaction log increases over time, it is imperative that these are written to disk using hard commit periodically.

Near Real Time Search (NRT): The /get NRT handler ensures that the latest version of a document is retrieved. It is NOT designed to be used as full-text search. Instead, its responsibility is the guaranteed return of the latest version of a particular document. When a /get request is raised by providing an id or ids (a set of id), the search process is as follows –
It checks if the document is present in the transaction log
If yes, then the document is returned from the transaction log
If no, then the latest opened searcher is used to retrieve the document

Atomic Updates:  Atomic Updates is a new feature in Solr 4.X that allows you to update on a field level rather than on a document level (previous versions of Solr). This means that you can update individual fields without having to send the entire document to Solr with the update fields’ values. Internally Solr re-adds the document to the index with the updated fields. Please note that fields in your schema.xml must be stored=true to enable atomic updates.


Related Articles:

Need Consulting help ?

Name

Email *

Message *

DISCLAIMER
All posts, comments, views expressed in this blog are my own and does not represent the positions or views of my past, present or future employers. The intention of this blog is to share my experience and views. Content is subject to change without any notice. While I would do my best to quote the original author or copyright owners wherever I reference them, if you find any of the content / images violating copyright, please let me know and I will act upon it immediately. Lastly, I encourage you to share the content of this blog in general with other online communities for non-commercial and educational purposes.

Followers