Hi Alex and Wei Zhou, Thanks for the input, so it seems this new feature is more beneficial for those who are currently using Shared Networks.
We have 50 AutoscaleGroups in a single VR because our company mainly distributes/broadcasts stock prices from multiple exchanges to public users, so lots of micro services that need to autoscale instantaneously when the markets suddenly spike/rally which can result in 1 - 10x traffic bursts. However, most of our Autoscale Groups consists of API Gateways to route traffic to different network tiers and micro services. This is what takes up lots of Autoscale Groups. We had to duplicate lots of API Gateway into multiple Autoscale Groups because the current feature only allows load balancing to 1 single port. So this is more of a workaround for us to overcome the current Autoscale feature limitation. I think something worth mentioning is that our Autoscale Group, load balances traffic to other Autoscale Groups. For example: Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> Database And in some cases, we have this as well: Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> ASG LB (Microservice 2)-> Database I guess makes the VR very busy. Happy to share more, sounds like our use is bit extreme… but it works so far though. Its only the CPU Utilisation that’s concerning… (memory is always around 40% so not a bottleneck there) Regards, Bryan On 29 Aug 2024 at 11:27 PM +0800, Alex Mattioli <alex.matti...@shapeblue.com>, wrote: > Hi Bryan, > > What's your use case for 50 autoscale groups in 1 VR? When designing the > feature we never envisioned more than 2 or 3. > > In NAT mode you should be able to get some 3gpbs through the VR, in ROUTED > mode then some 6-7gbps. Those numbers do go down (considerably sometimes) > with the number of firewall rules, load balancing, etc... you have setup in > the network. > > You'll need to create new networks in ROUTED mode, there's no migration path > from NATTED mode to ROUTED mode. > > You definitely can allow all traffic in the firewall and setup firewall rules > in each individual VM. > > In this initial implementation there's no load balancer in ROUTED mode, so no > Autoscale groups. But it is definitely a possible improvement for future > versions. > > Cheers > Alex > > > > > -----Original Message----- > From: Bryan Tiang <bryantian...@hotmail.com> > Sent: Thursday, August 29, 2024 11:11 AM > To: us...@cloudstack.apache.org; us...@cloudstack.apache.org > Cc: dev@cloudstack.apache.org > Subject: RE: Port Forwarding in Network > > Hey Alex, > > It’s exiting to hear this new features coming about, and that the VR > performance will be improved as a result of pure routing. > > We have a pain point right now where our VR is at 75% CPU when handling > 200Mbps Internet Traffic. Probably because we have 50 Autoscale Groups within > that 1 VR… (VR is 4Core,4GB). > > We have plans support 1Gb-5Gbps Internet Bandwidth within a single VR one > day, but if it’s already at 75%… kinda worrying for us. So this is exciting. > > I went through the design document and have few questions. Is this going to > be a new network? Or can existing VPC networks upgrade to Routed Mode? > > Since every VM will get to have its own Public IP, does it mean every VM can > have its own firewall rules now? > > Will this feature be available for Autoscale Groups? We are heavy users of it. > > Regards, > Bryan > On 29 Aug 2024 at 4:22 AM +0800, Alex Mattioli <alex.matti...@shapeblue.com>, > wrote: > > Hi Marty, > > > > > > > > Here's the documentation for Routed Mode and Simple Dynamic Routing, I did > > the original design and my colleague @Wei > > Zhou<mailto:wei.z...@shapeblue.com> refined and implemented it. > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=306153967 > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=315492858 > > > > Cheers, > > > > Alex > > > > > > > > > > > > > > > > -----Original Message----- > > From: Marty Godsey <mar...@rudio.net> > > Sent: Wednesday, August 28, 2024 11:07 AM > > To: us...@cloudstack.apache.org > > Subject: Re: Port Forwarding in Network > > > > > > > > Thank you, Alex. I am excited about that addition. Even having the ability > > to not have to NAT is very useful. > > > > > > > > Regards, > > > > Marty Godsey > > > > Rudio, LLC > > > > > > > > Book Time: https://calendly.com/rudio-martyg > > > > Support: > > supp...@rudio.net<mailto:supp...@rudio.net?subject=Rudio%20Support<mailto:supp...@rudio.net%3cmailto:supp...@rudio.net?subject=Rudio%20Support>> > > > > Ph: 859-328-1100 > > > > The content of this email is intended for the person or entity to which it > > is addressed only. This email may contain confidential information. If you > > are not the person to whom this message is addressed, be aware that any > > use, reproduction, or distribution of this message is strictly prohibited. > > If you received this in error, please contact the sender and immediately > > delete this email and any attachments. > > > > > > > > > > > > From: Alex Mattioli > > <alex.matti...@shapeblue.com<mailto:alex.matti...@shapeblue.com>> > > > > Date: Tuesday, August 27, 2024 at 11:56 AM > > > > To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> > > <us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org>> > > > > Subject: RE: Port Forwarding in Network > > > > WARNING: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe. > > > > > > > > > > > > Hi Marty, > > > > > > > > There are two PRs in progress, one for Routed Mode for IPv4 in Isolated > > Networks and VPCs and another for Simple Dynamic Route with BGP. > > > > > > > > With Routed Mode you'll be able to assign public IPs directly to VMs, this > > should be ready for ACS 4.20, which will be routed via the ACS VR. > > > > This has been possible for IPv6 since ACS 4.17 and will work in a similar > > way (with some differences) for IPv4. Here's a video explaining how it > > works for IPv6: https://www.youtube.com/watch?v=UvCSmU1TjRY&t=1583s > > > > > > > > As mentioned before, if you want to skip the VR completely then you need to > > use Shared Networks, but then end users can't deploy the networks > > themselves without operator intervention. > > > > > > > > Cheers > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Jayanth Babu A > > <jayanth.b...@nxtgen.com.INVALID<mailto:jayanth.b...@nxtgen.com.INVALID>> > > > > Sent: Tuesday, August 27, 2024 10:27 AM > > > > To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> > > > > Subject: Re: Port Forwarding in Network > > > > > > > > Hi Marty, > > > > Please use Shared Networks [1]. > > > > > > > > [1] > > https://atpscan.global.hornetsecurity.com/?d=xMOwK4fYoexeGDaCItpovxDkoPdExpSMKaLuotztWEw&f=1X9ll9UDNTAUv9XEhAoS-oCZLIFMKLOf3SQZgHrZSZlrXbexUH8NtKLJCqQbeAYB&i=&k=bm7B&m=x1rGyep2ImM3kF-8P6y1JWh7yEkoCGNNgU8oyJkxPaALdf4b2xt3n4PE01uT1okjgB6Kw5tM2yIKoLpa6cjYlK58irpRbdjWYflteXydz9OVb4jJgpLPFwQzFkj2QYTn&n=qT4mJ0BYBeh6jAxOCD1hayLTVyupmjmzwzzkOhAmOF4z7wMla_tk04lc9D939Rfl&r=IVbx63cjnjXzXq_Sv0qS0mvAEousFhnYo0ONd_j_NKawfjzf9DWkEB-VcJALkcaL&s=40bdd3dc1b6d4512eb8828b1f28bd4d08a871934dab0ba463a647f6e5f009a36&u=https%3A%2F%2Fdocs.cloudstack.apache.org%2Fen%2Flatest%2Fadminguide%2Fnetworking.html%23shared-networks > > > > > > > > Thanks, > > > > Jayanth > > > > > > > > ________________________________ > > > > From: Marty Godsey <mar...@rudio.net<mailto:mar...@rudio.net>> > > > > Sent: Tuesday, August 27, 2024 6:38:12 pm > > > > To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> > > <us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org>> > > > > Subject: Re: Port Forwarding in Network > > > > > > > > This is what I went ahead and used. > > > > > > > > Has there been a feature request to create a way to directly provide a > > public IP to an instance instead of using a VR? > > > > > > > > Regards, > > > > Marty Godsey > > > > > > > > > > > > From: Jithin Raju > > <jithin.r...@shapeblue.com<mailto:jithin.r...@shapeblue.com>> > > > > Date: Tuesday, August 27, 2024 at 12:06 AM > > > > To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> > > <us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org>> > > > > Subject: Re: Port Forwarding in Network > > > > WARNING: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe. > > > > > > > > > > > > Hi Marty, > > > > > > > > Could you use static NAT instead? > > > > > > > > -Jithin > > > > > > > > From: Marty Godsey <mar...@rudio.net<mailto:mar...@rudio.net>> > > > > Date: Monday, 26 August 2024 at 9:26 PM > > > > To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> > > <us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org>> > > > > Subject: Port Forwarding in Network > > > > Is there a way to easily forward all ports without having to put in 1 – > > 65525? I know it’s small and petty, but in other places, you can do a -1 to > > specify all. You don’t seem to be able to do that here. > > > > > > > > Regards, > > > > Marty Godsey > > > > > > > > > > > > > > > > Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION > > intended solely for the use of the addressee(s). If you are not the > > intended recipient, please notify the sender by e-mail and delete the > > original message. Further, you are not authorised to copy, disclose, or > > distribute this e-mail or its contents to any other person and any such > > actions are unlawful and strictly prohibited. This e-mail may contain > > viruses. NxtGen Datacenter & Cloud Technologies Private Ltd (“NxtGen”) has > > taken every reasonable precaution to minimize this risk but is not liable > > for any damage you may sustain as a result of any virus in this e-mail. You > > should carry out your own virus checks before opening the e-mail or > > attachment. NxtGen reserves the right to monitor and review the content of > > all messages sent to or from this e-mail address. Messages sent to or from > > this e-mail address may be stored on the NxtGen e-mail system. *** End of > > Disclaimer ***NXTGEN***
