0

I have setup 2 instance under aws load balancer. I have deployed node.js web services + mongodb in both instance. load balancer works fine with web services.

But, Problem is I have one timer service (node.js service only). the behavior of this timer is updating my mongodb based on some calculation.

My problem is, I must need to run this timer service (timer.js) at only one aws instance (out of 2) at same time. and expected that if one aws instance goes down then timer service at other instance will come up.

i know elb not providing this kind of facility.Can any one please help me to make it done ?

Condition : At a time only one timer service must be run with amazon load balancer.

Thanks.

Hemang
  • 85
  • 3
  • 11
  • I don't see how the ELB comes into play in this question? Could you please clarify. Is your timer.js called from outside AWS using a URL ? – greg_diesel May 07 '15 at 15:36
  • Hi greg, timer service is on aws instance only. timer is not web service. it is working like scheduler job for me. that's why i mention in my question that elb has no any configuration for this type of timer service. but i want to fail ever timer service. how to make it done? – Hemang May 08 '15 at 05:31

2 Answers2

0

You would have to implement this yourself using a locking algorithm using a shared data store that supports atomic operations

Alternatively, consider starting a "timer" server in an Auto Scale Group of Min:1, Max: 1 so Amazon keeps it running. This instance can be a t2.micro which is very cheap. It can either run the job itself, or just make an http request to your load balancer to run the job at the desired internal. If you so that, only one of your servers will run each job

Max
  • 8,671
  • 4
  • 33
  • 46
  • Thanks Max, I also thinking for setup my timer service on different server. micro instance is more than enough. but my requirement is to make fail over for timer service. if i put it on single micro service i will not able to fail over it. what will you suggest for it ? – Hemang May 08 '15 at 05:24
  • That's why it's in an auto scale group. You can set up monitoring of some sort to detect application failure, and the auto scaling group makes sure that if the instance dies, a new one replaces it – Max May 08 '15 at 05:28
  • Yes. that also make sense. we can go with auto scaling. – Hemang May 08 '15 at 05:36
  • Also i though about to create manual health check from my web service and will check status of timer from my second instance. if any failure got, then i will start timer on my second instance. that make sense or not? is it correct way to do this ? – Hemang May 08 '15 at 05:38
  • Sounds like that will be complex and overkill. Maybe use a service line Pingdom which will monitor the instance and if it goes down it will email you. If you design the instance well, you shouldn't have problems. – Max May 08 '15 at 05:44
0

Wouldn't it make more sense to handle this like any other "service" that needs to keep running?

upstart service
running node.js server using upstart causes 'terminated with status 127' on 'ubuntu 10.04'
This guy had a bad path in his file but his upstart script looks okay

monit
Node.js (sudo) and monit

Community
  • 1
  • 1
greg_diesel
  • 2,955
  • 1
  • 15
  • 24