SharePoint Search Topology:

• Scalable - content and query load
• Fault-tolerant
• Appears as a SharePoint SSA
• Manage using PowerShell
• Status from UI/PowerShell

Set up your initial search topology:

• New-SPEnterpriseSearchTopology
• New-SPEnterpriseSearchIndexComponent, New-SPEnterpriseSearchQueryProcessingComponent, ....
• Set-SPEnterpriseSearchTopology

Scale out your search topology to add performance or capacity:

Create and edit a copy of your active topology:
>>New-SPEnterpriseSearchTopology-Clone
Note:  You never modify the active topology object

Add before remove:
Add components >> Activate >> Green state >> Remove components >> Activate

Location of files on disk matters!:

Local disk for index files!
Index operations are I/O demanding

Per Index Component:
Separate data folder for the index files
When creating a new index component:
  >>New-SPEnterpriseSearchIndexComponent -RootDirectory E:\Index

ULS Logs:
Prevent disk contention/flooding
Set-SPDiagnosticConfig -LogLocation F:\Logs

Scale out by re-partitioning the index:

When each index partition exceeds 10 million items
Stateless partitioning using consistent hashing
Start with a symmetric index layout

Understanding component issues:

Yellow(degraded) >> Transient component lifecycle states-Restarts and topology changes.
                                   Index replica not in sync


Red(failed/unknown) >> Indicates that server, or search component, is unreachable
                                        HW/Network issues
                                        CmdLet: Will normally appear as unknown


Get-SPEntepriseSearchStatus provides more details

Get-SearchTopologyState.ps1 -> One stop shop for search status (download from TechNet wiki)

Search Health Reports - Query

Search Administration >> Diagnostics
Query Performance >> Query latency/rate
Federation >> Per result source
Query/feeding >> Query latency/feeding rate correlation

Backup and Restore

Everything but the index is in databases
Restore possible to a different deployment -> May use B/R for standby DR location; Restore location must have the same topology
Ballpark figures -> 8 hours to backup 80M document index: 2TB of data, 6 hours to restore
SharePoint farm -> Recommended approach; Part of SharePoint backup/restore
DB-only backup/restore -> Primarily when moving DB servers
Volume Shadow Copy -> Customer application controls backup; Selective snapshot, including the index; Search is down for a longer period of time