[cisco-voip] Call Manager Service restart

[Techguy]

Hi Anthony,
I agree with you, Tim and I came to the same conclusion, but this gets a
bit interesting with the following scenario. Consider cm group of two
servers distributed as such to max capacity in fail-over condition. Now if
only a cm service restart is intended, should a restart take preference
over stop and start? assume no testing is required in a failed over
scenario. I wonder this would prohibit the secondary server to be fully
loaded and overwhelmed with all endpoints than some (of the primary ones)
and let them all reg to the primary one since it came back already. (OR) is
it that once the cm restart is initiated then all of it's endpoints 'must'
reg to the secondary before they go back to primary, no matter how quick
the primary comes back up and running/available.
your thoughts are welcomed!
Thanks
tg


On Tue, Oct 22, 2013 at 9:55 PM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> Personally, I have seen web pages fail on me too many times over the years
> to trust a simple restart of services.  I would always opt for a stop,
> wait, confirm, then start, versus a restart.  That's my personal
> preference.  And yes, restarting and stop/start will achieve the same
> results, if you don't in fact need down time.  I.e., If you stopped the CM
> services where phones are registered, then they cannot fail back until you
> start it; however, if you elect for a restart, then phones will fallback as
> soon as their timers tell them to do so; which may or may not give you
> enough time for your test/validation.
>
>
> On Tue, Oct 22, 2013 at 5:15 PM, Techguy <techguy.ca at gmail.com> wrote:
>
>> Hi Folks,
>> Would restarting the service achieve the same as stopping it and starting
>> it with pauses to ensure proper fail-over to the secondary cm
>> occurs/verifies first? any thoughts?
>>
>>  Thanks
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131022/8c3db901/attachment.html>