Persistent EC2 Instance for FSx file syncing with external server.

0

How would one deploy an EC2 instance (say a basic g4dn) within the nimble studio VPC? What subnet and security groups would it need to be on so that I can connect to the AD and the FSx volume.
This would be purely used as an instance for storage administration so having it launch within the Nimble studio GUI is not necessary. Basically, I need a non-ephemeral instance running syncing software 24/7 that is connected to the Nimblestudio VPC.

已提問 3 年前檢視次數 236 次
3 個答案
0

Hi,

this depends if you need it to be publicly visible (public IP) or if it can stay private within the VPC. If it needs to stay publicly available you can use the subnet called Public which is pre-configured for this. In terms of SecurityGroups you want to design your own to open up the ports/protocols you need for that storage sync. If it can stay private (only accessible within the VPC) I would recommend either the Filesystems or WorkerSupport Subnets.

已回答 3 年前
0

Thank you!
This works (kinda). I am able to login to the ec2 instance via RDP on a nimble-generated computer. However, after successfully joining the AD, when I attempt to login it fails and sets up a temp profile.

I think this might be because it is unable to mount the fsx volume (which contains all roaming user information) on user login...

已回答 3 年前
0

Got this figured out with an AWS tech. This is part of the recap: First, we sorted out the issue with with eth0 and eth1. Your intention was to have one public and one private ENI attached to your instance, but both of the ENIs were private (one had outbound access, but via a NAT). We determined that eth1 was redundant and caused nslookup against the domain to fail, likely because communication defaulted to eth0. So, we simply detached eth1. We added the DNS addresses of your AD controllers to eth0, but determined that the nslookup query still fails and you get an NLA error upon RDP indicating that the domain couldn't be contacted.

The issue was that the CloudFormation stack launched subnets and ACLs that were very restrictive. The ACLs didn't allow communication between the subnet you launched your instance into and your AD controllers. We added the necessary ingress and egress rules to the AD subnet ACL and your instance subnet ACL, which resolved the NLA error, but attempting to log in with Admin still resulted in only being logged on with a TEMP profile. Then, I remembered from your use-case and the fact that Nimble creates roaming profiles on the FSx that your instance likely doesn't have access to the FSx, either.

已回答 3 年前

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。

回答問題指南