Yes, this is a common error I've seen in the past even with MongoDB, keeping all the replica on the same Box and on the same storage defice. Even with virtualization I always suggest having at least disks on different and distinct SAN. VM usually runs on vSphere or Hyper-v with SCVMM so they can tolerate failure of the hardware with live migration.
Thanks. -- Gian Maria Ricci Cell: +39 320 0136949 -----Original Message----- From: Emir Arnautovic [mailto:emir.arnauto...@sematext.com] Sent: venerdì 22 gennaio 2016 11:57 To: solr-user@lucene.apache.org Subject: Re: Couple of question about Virtualization and Load Balancer There is other reason to avoid virtualization - fault tolerance. It is common to use virtualization on huge box and keep replications on same box. Such setup will survive VM failure but not HW failure. Regards, Emir On 22.01.2016 11:05, Gian Maria Ricci - aka Alkampfer wrote: > Thanks, my actual strategy is using SolrMeter to test with real > Virtualized hardware and real result set to gain some number. The > customer definitively wants virtualization, and probably we will not > test on bare metal installation. > > As I state in previous mail, the question arise because in some books > / blog, people suggest to avoid virtualization, and even if I know > that a virtualized hardware is slower than bare metal, usually the > loss of performance is negligible, so I wander if there are some proof > of concepts to back up these hypothesis. > > As I suspected, probably that is a general advice, but it is always > safer to have a proof of concept on your hardware and data. > > Thanks. > > > -- > Gian Maria Ricci > Cell: +39 320 0136949 > > > > -----Original Message----- > From: Davis, Daniel (NIH/NLM) [C] [mailto:daniel.da...@nih.gov] > Sent: gioved? 21 gennaio 2016 16:32 > To: solr-user@lucene.apache.org > Subject: RE: Couple of question about Virtualization and Load Balancer > >> The first one is about virtualization, I'd like to know if there are >> any official test on loss of performance in virtualization >> environment. I think that the loss of performance is negligible, and >> quick question on test infrastructure is confirming this, but I'd >> like to > know if there is some official numbers on this. > > I think any "official" test would run into the very reasonable problem > of which schema, indexed data, and queries to test. > This problem is well summarized by > https://lucidworks.com/blog/2012/07/23/sizing-hardware-in-the-abstract > -why-w > e-dont-have-a-definitive-answer/. > > However, there is a Solr performance test tool with a track record - > SolrMeter<https://github.com/tflobbe/solrmeter/blob/wiki/Usage.md>. You > can also do a lot with good old JMeter. > > From: outlook_288fbf38c031d...@outlook.com > [mailto:outlook_288fbf38c031d...@outlook.com] On Behalf Of Gian Maria > Ricci > - aka Alkampfer > Sent: Thursday, January 21, 2016 6:38 AM > To: solr-user@lucene.apache.org > Subject: Couple of question about Virtualization and Load Balancer > > Hi, > > I've a coupl > e of quick question about production setup. > > > The second question is about Load Balancer: any clue on how to > automatically change the configuration on the load balancer if some of the node goes down? > I'm looking to advices on what to monitor, the simplest solution could > be issuing some test query and verify if the node is able to answer, > but it would be nice to know if there are some standard metrics to > monitor to proactively alert. (Es. Heap size almost full, so it would > be probably better to remove the node from the balancer and alert a human to have a look > at the status of the node). > > Many thanks. > > -- > Gian Maria Ricci > Cell: +39 320 0136949 > [https://ci5.googleusercontent.com/proxy/5oNMOYAeFXZ_LDKanNfoLRHC37mAZ > kVVhkP > N7QxMdA0K5JW2m0bm8azJe7oWZMNt8fKHNX1bzrUTd-kIyE40CmwT2Mlf8OI=s0-d-e1-f > t#http > ://www.codewrecks.com/files/signature/mvp.png]<http://mvp.microsoft.co > m/en-u > s/mvp/Gian%20Maria%20Ricci-4025635> > [https://ci3.googleusercontent.com/proxy/f-unQbmk6NtkHFspO5Y6x4j > lIf_xrmGLUT3fU9y_7VUHSFUjLs7aUIMdZQYTh3eWIA0sBnvNX3WGXCU59chKXLuAHi2Ar > WdAcBc > lKA=s0-d-e1-ft#http://www.codewrecks.com/files/signature/linkedin.jpg] > <http://www.linkedin.com/in/gianmariaricci> > [https://ci3.googleusercontent.com/proxy/gjapMzu3KEakBQUstx_-cN7gHJ_Gp > cIZNEP > jCzOYMrPl-r1DViPE378qNAQyEWbXMTj6mcduIAGaApe9qHG1KN_hyFxQAIkdNSVT=s0-d > -e1-ft #http://www.codewrecks.com/files/signature/twitter.jpg] > <https://twitter.com/alkampfer> > [https://ci5.googleusercontent.com/proxy/iuDOD2sdaxRDv TwS8MO7-CcXchpNJX96uaW > uvagoVLcjpAPsJi88XeOonE4vHT6udVimo7yL9ZtdrYueEfH7jXnudmi_Vvw=s0-d-e1-f > t#http ://www.codewrecks.com/files/signature/rss.jpg] > <http://feeds.feedburner.com/AlkampferEng> > [https://ci6.googleusercontent.com/proxy/EBJjfkBzcsSlAzlyR88y86YXcwaKf > n3x7yd > AObL1vtjJYclQr_l5TvrFx4PQ5qLNYW3yp7Ig66DJ-0tPJCDbDmYAFcamPQehwg=s0-d-e > 1-ft#h ttp://www.codewrecks.com/files/signature/skype.jpg] > -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/
