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.

posta 3 anni fa236 visualizzazioni
3 Risposte
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.

con risposta 3 anni fa
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...

con risposta 3 anni fa
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.

con risposta 3 anni fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande