Azure-Samples / graphrag-accelerator

One-click deploy of a Knowledge Graph powered RAG (GraphRAG) in Azure
https://github.com/microsoft/graphrag
MIT License
1.65k stars 250 forks source link

[QUESTION] Deployment with ./deploy.sh with integration with VNET and PRIVATE ENDPOINT #122

Open jamil77944 opened 1 month ago

jamil77944 commented 1 month ago

Hi, Below is the error I am receiving when I enable the private endpoint=true. Somehow the vnet returns a null value.

Screenshot 2024-08-01 144147

This below error happens when the private endpoint=false. The AKS Cluster tries to connect with another resource group which I lack access.

Screenshot 2024-08-01 144806

Can you please help with the issues described above? In addition to that, Is there any way to disable the VNET integration?

timothymeyers commented 1 month ago

Keep an eye on #123; it may help with your deployment.

When you say "private endpoint=true", do you mean you ran deploy.sh without -d or -g?

The resource group MC_rg-emt... appears to be the AKS resource group created as part of any AKS deployment.

I need some more context to help you debug. Do you have your deploy.sh output saved somewhere? Are there other failures in your Resource Group / Deployments tab in the portal?

These failures look to me like an earlier step did not complete correctly somehow.

rnpramasamyai commented 1 month ago

@jamil77944 To see errors on the Azure portal, go to your resource group where you deployed your resources, click on "Deployments," and it will show you a list of deployments, including any errors in the deployment process.

moapurva commented 1 month ago

Network architecture update from the engineering team. Please deploy to a new resource group as it introduces breaking changes: https://github.com/Azure-Samples/graphrag-accelerator/pull/123

jgbradley1 commented 1 month ago

Hi @jamil77944, I'm looking over a couple of the issues you've opened and there might be some cascading issues occurring here. Last week, we simplified the network architecture down to a single vnet.

We use vnet integration between the AKS and APIM resources (instead of public endpoints) for security reasons. Currently, we have not added a flag to the deploy.sh script to disable vnet integration.

One thing I would recommend checking is the cloud region you're deploying in. When I look up quota in the eastus region for the VM type standard_d4s_v5, I get the following warning:

Standard DSv5 Family vCPUs are high in demand in East US. To request access or get recommendations select troubleshoot.

This specific VM type is used in the AKS deployment. In my case, even though the subscription has quota for this VM type, a deployment will still fail due to the high demand occurring. I attempted to do a deployment in eastus and after digging into the deployment log, I found this message:

The requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: standard_d4s_v5' is currently not available in location 'eastus'

I recommend trying either the eastus2 or westus2 regions if you can.