Deployment Considerations – Fault Tolerance:
Another key dimension that determines server sizing and deployment architecture is Fault Tolerance. What processes can we potentially do without if a server fails. For instance, Is the freshness of content critical?
Do we really need to provide Admin fault tolerance. FAST ESP is designed to keep feeding, indexing and search working even if the Admin node goes down. Also restart of one or more system parts is possible without the Admin node available due to cached configuration data.
3 fault tolerance models:
Fail Safe = Full Redundancy/ Mirroring. If any single node goes down there is a mirrored version standing by ready to take its place.
Fail Soft = Mirroring of the QR & Search nodes. If any of the other nodes go down we can still serve queries until they come back online.
# Fail Stop = Installing ESP on a Single server. This is not recommended. If the server goes down we have no way of interacting with the system.
LAS - Local Attached Storage using standard built in disks are one of the most common forms of storage for smaller organisations. We recommend the use of at least RAID 5. This combines 3 or more disks by mirroring and stripping to prevent against failure of any on disk.
SAN – With a SAN we eliminate
In order to calculate the cost of potential down time versus the cost of additional hardware
We need to ask questions like:
- What is the cost to the business of downtime?
- What are the likelihood of severe failures?
- Indexing, Document processing, user-interactions can run on seperate nodes? Which of these would require fault-tolerance?
Min. System Requirements:
FAST ESP roots are as a platform agnostic vendor, that means it can run on any of the standard platforms. Microsoft has agreed to support that going forward.
I have cobbled together a list of some of the minimum system requirements for an installation of FAST ESP as well as some of the necessary prerequisites.
No comments:
Post a Comment