In a correctly configured, healthy cluster, I can't recall a situation when a single disconnected SDS would cause a DATA FAILURE state.
Can you please check in the GUI (or CLI - scli --query_sds) if there are any devices in the Error state?
Probably the best way of investigation would be through the Service Request, so we can view all the logs and see what exactly was going on there - please open an SR and we'll take it from there.
Was there any rebuild activity already going on when the SDS disconnected?
This can happen when already some rebuild activity was going on and another SDS fails. In that case both the combs for certain data may not be available.
Following 2 events show that even after the SDS was reconnected, Data was still in degraded state:-
48830745 2017-02-07 17:55:23.490 SDS_RECONNECTED INFO SDS: devvirtp0024l00 (ID 1ce2de4e00000003) reconnected
48830770 2017-02-07 17:55:24.649 MDM_DATA_DEGRADED ERROR The system is now in DEGRADED state.
Hi, any rebuilding or re-balancing activities was noticed during SDS shut off.
Data was degraded after sds reconnected because IO was happening and some data needed to be rebuild. Also DRL was cleaned so degraded is normal after SDS was connected. but failed capacity is not expected and unacceptable.
We tried it on 4 SDS nodes (each time cluster was healthy) and in all times failed data was detected.
Hello, it seems we were running SW bug, with checksum protection enabled. We disabled checksum protection, and tried maintenance mode and SDS off. worked perfectly. So root cause Checksum protection. Thank you.
pawelw1
306 Posts
1221
1
Posted February 8th, 2017 05:00
Hi Matas,
In a correctly configured, healthy cluster, I can't recall a situation when a single disconnected SDS would cause a DATA FAILURE state.
Can you please check in the GUI (or CLI - scli --query_sds) if there are any devices in the Error state?
Probably the best way of investigation would be through the Service Request, so we can view all the logs and see what exactly was going on there - please open an SR and we'll take it from there.
Thank you,
Pawel