This is obviously on us for just using the “typical” mediasoup ports, we just didnt ever hit this issue when using webRtcTransports w/o webRtcServer since we weren’t specifying the exact port we wanted. Hope this saves someone some time and frustration in the future. The ephemeral range can vary between OS’s and distributions so do your own due diligence here. The virtual devices for instance store volumes are ephemeral0-23. So we have now moved our mediasoup webRtcServer ports outside this larger ephemeral range. AWSDocumentationAmazon EC2User Guide for Linux Instances. Node 6523 webapp 1033u IPv4 46295 0t0 TCP :40000->:6379 (ESTABLISHED)Īnd this would only happen randomly when the OS selected such a port, and we failed to initialize the worker prior to trying to hit redis (or whatever external service that needed TCP). to redis: lsof -i :40000ĬOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME What this meant is that it would use ports in this range when establishing outgoing connections, e.g. They appear to have a much larger ephemeral range than some other distributions and larger than what you might find when googling for what the usual ephemeral range is: ~]$ cat /proc/sys/net/ipv4/ip_local_port_range ![]() It turns out that port 40000 is in the “ephemeral port range” for these EC2 instances. We thought maybe we had a race in how we initialized workers, but eliminated that. Uv_listen() failed : address already in use We started randomly getting errors like this: We kept our webRtcServer ports in the low 40000 range as the mediasoup demo is setup (and how we have been setup using just the normal webRtcTransport range for some time) and setup workers to use a separate range. We recently moved to using the new webRtcServer. Information on adding and validating tests for PRs.Just dropping this here in case someone else hits this problem. Improvements and bug fixes are greatly appreciated. Tempdb is typically the most heavily used database, so it benefits from the fastest available drive. This ensures that the backup device is always as up-to-date as the cache device, and it can always be used without the cache device. Write through: All writes go to both cache and backup. Location the volume should be mounted Limitations We recommend that you place tempdb on an instance store volume for two reasons: speed and cost. This is not useful for EC2 ephemeral setups, as it will render your backup device useless on a crash or stop. You just have to remember that when you terminate an EC2, your ephemeral storage (the storage that is part of your EC2) is erased, but if you use an Elastic. To mount the disks: class Reference Class aws_mount Parameters To install the evenup-aws_mount module: puppet module install evenup-aws_mount It is recommended to run this module in a stage prior to 'main' (such as setup if you're using puppetlabs/stdlib) to ensure the volume is available for the rest of your modules. This module is designed to automatically mount and create a RAID0 array from any ephemerial disks on AWS instances. ![]() ![]() Puppet module to mount AWS EC2 ephemeral disks Module Description Development - Guide for contributing to the module.Reference - An under-the-hood peek at what the module is doing and how.Usage - Configuration options and additional functionality.Setup - The basics of getting started with aws_mount.Module Description - What the module does and why it is useful.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |