Request to add PSC Endpoint connection to Google Cloud NetApp Volume

[TJ]

Hi there Google Cloud community, Terraform community, and NetApp community:

Simple question: Google has two basic ways to link services in a Google Cloud virtual private network:

1. Private Services Connect
2. Private Services Access

Per this excellent Medium article:

Accessing Google APIs via Private Service Connect(PSC) and Private Google Access (PGA) | by Kishore ...

Why has NetApp, and/or Google Cloud NetApp, only enabled the second option, of the Private Services Access?

Is there any way to, with all due respect, ask for who is the appropriate team leader or code dev community who could add this functionality, to connect with Google Cloud NetApp via Private Services Connect, especially in Terraform code please?  It seems like with Google Cloud NetApp offering a suite of services while conserving costs, having the ability to link, say, a GKE-to-Google Cloud NetApp by way of Private Services Connect, would also offer an enhanced connect option for everyone in the community, that is streamlined and more affordable than setting up a peering network. 

Thanks,
Tim James

p.s.  I've posted this same question, with additional details, in the Terraform community here:

https://discuss.hashicorp.com/t/request-to-add-psc-endpoint-connection-to-google-cloud-netapp-volume...

[alexmoore · Accepted solution]

Hi there,

This is a great question.  I would first just call out that the article linked talks about Private Service Connect (PSC) and Private Google Access (PGA), however your question relates to Private Service Connect (PSC) and Private Services Access (PSA), so slightly different - but of course very related topics.

The short answer is PSA pre-dates PSC, and so many services that require presentation of a private IP from a managed service like Google Cloud NetApp Volumes use PSA.  PSC was introduced more recently and so not all services support it today, but more are being added all the time and as with all things on the cloud it is constantly evolving, so keep an eye out on release notes as this may be added in the future for the NetApp service.  

Ultimately though PSA and PSC are achieving the same thing for your use case, just using different underlying mechanism (PSA uses peering, PSC presents an endpoint), but you should have no problem using PSA to reach the NetApp service securely plus it can easily be setup via Terraform, check out the documentation here:

https://registry.terraform.io/providers/wiardvanrij/ipv4google/latest/docs/resources/service_network...

Some more details on PSA and PSC can be found in this comparison table here: 

https://cloud.google.com/vpc/docs/private-access-options#connect-services

Hope that helps,

Alex

[TJ]

Hi Alex,

Thank you for your prompt response.

Yes, that is certainly interesting to learn.  I hadn't fully understood there was a third option, with the available connection services per your reference link, including the PSC, PSA, and PGA (not to be confused with the pro golf league 🙂).

In reviewing these three services, it looks like Google is making more than one option for setting up infrastructure which is nice.

At the same time, my research into PSA, based upon various feedback of those who have implemented it, is that there is slightly more chance of either data loss or data error, due to the nature of setting up a peering network, where the data transfer passes through a transitional phase -- whereas setting up an endpoint connection, such as PSC, is more of a direct link.

I have already setup the Terraform code to link my GKE-to-Google Cloud NetApp storage pool via PSA, and it's tested and working properly.  However, my initial testing also had setup my GKE-to-Cloud SQL via PSA initially, using a separate peering network.  When I then tested the Terraform code to setup the GKE-to-Cloud SQL link via PSC, it seemed like not only cleaner code but also the billing was more cost conservative since the endpoint with a direct link uses less daily bandwidth transfer usage compared to setting up a peering network with PSA.

So the question I had was essentially: since NetApp markets itself as a feature-rich and more cost conservative file storage option, than say Google Filestore, then wouldn't enabling a PSC link be the next step in the process?  And if this is an area that could be obviously  beneficial for many people in the community, where is the appropriate place to put in a request for this as-yet undeveloped next step to be identified and expand the horizon?  

Like you mentioned, I can use the PSA for now in dev testing purposes, and hopefully a PSC link will be enabled by the time my company project is ready for live production deployment.

Thanks, Tim

[alexmoore]

Hi Tim,

What references have you seen for PSA leading to data loss or data error?  From a data transit standpoint there should be no difference, ultimately both PSA and PSC use IP protocols to reach the service.  And in the case of file serving protocols like CIFS and NFS both have robust error recovery mechanisms in the event of packet loss (which in any case should be rare).  In any case from a network reliability/stability standpoint you should see no difference between either service.

PSC more generally introduces a wider range of connectivity options for inter-service/project/org communications in both directions with more granular traffic control and security options, which is why it was introduced.

A couple of points on your point on daily bandwidth transfer, first the daily data transfer volume will depend entirely on what you accessing on the NetApp volumes, there should be no difference between PSA and PSC if you are accessing the same data.  Then on the cost front, typically I would expect to see a slightly higher cost for PSC as there is an hourly charge for the endpoint, whereas PSA has no standing charge, but again these can vary depending on your specific configurations and traffic patterns.

With regards to the feature support for PSC for Google Cloud NetApp Volumes, you can raise feature requests for PSC here: https://issuetracker.google.com/issues/new?component=1132240

All the best,

Alex

[TJ]

Hi Alex,

I was the recipient of a Google 2k scholarship award a few years ago, and I've been doing a lot of research and dev testing since then on my work project, to build out a Magento 2 site for my business on GCP, using the latest and best GKE platform.  The learning curve was a lot of education, from discovering how GKE operates to how to put together a virtual private network in order to add Google services including the Cloud SQL and, well initially it was Filestore, but now I'm testing Google NetApp instead.

Having said that, I've read in at least two different blog posts, or forum feedback posts, where other individuals have described peering networks as having a slightly greater risk of data loss or data error.  With Google Cloud, they described it as, in their experience, having 99.9% uptime with data preservation, so this topic is obviously on a very slim margin regarding data. 

Even though data loss or data error may be rare, if we look at a company website, like my current project, that would last for 5-10 years, those slim margins could accrue over time.  So that is certainly good to learn that the data reliability/stability is the same with either connection setup.  I always prefer to build on the latest protocols to try and future-proof setup, especially infrastructure, as long as it's within project budget constraints.

Another aspect was that I was influenced by the information in this article:

Everything You Always Wanted to Know About VPC Peering* (*But Were Afraid to Ask) | by Luca Prete | ...

Where the author recommends to limit the number of peering networks.  This article references the fact that setting up a peering network comes with an inherent drawback -- that you are basically exposing your virtual private network, at least on the approved CIDR ranges, to the peered Google network.

I was also under the impression that having a VPC peering connection came with inherent costs, but I went back today to re-review the GCP pricing for PSC compared with PSA, and at least for my project, your response is accurate in that the only cost difference is the endpoint hourly cost for PSC.  It may be possible that in my prior dev tests, I was routing slightly more data through the PSA link in those tests, which made it seem like PSC was the more cost conservative option.

In that regard, having this discussion has clarified a few notable aspects so that I can better learn how to build properly going forward.

Thank you for your feedback.

-Tim

[alexmoore]

Hi Tim,

Sounds like you have been doing your research, great to hear.

All networks can experience occasional packet loss for a wide variety of reasons and while of course Google engineers the platform to minimise this, it can happen.  However depending on the application using the network this typically should not directly result in actual data loss or errors, as the network protocols higher up the stack should take care of this, for example TCP has built in mechanisms to detect packet loss and re-transmit.  For occasional transient packet loss this should be completely transparent to the application, for sustained packet loss the application may exhibit network latency or connection failures, but most applications should be designed to handle such failures gracefully and not directly result in data loss, particularly network storage protocols like NFS and CIFS and database protocols like ODBC - for example raising errors up to the application if a write of data was unsuccessful.  That being said, it does depend on the application and protocols being used, for example if you are passing simple UDP traffic and have no logic in the application to detect or recover from errors, then you may well see data loss.

Google Cloud surfaces visibility of some of this data in Network Intelligence Center, have you seen this dashboard for example: 

https://console.cloud.google.com/net-intelligence/performance/global-dashboard

You can also configure specific connectivity tests for your own use cases to monitor particular paths, at the time of writing, up to 20 are free of charge, with a nominal cost beyond that.  See here for the latest costs: 

https://cloud.google.com/network-intelligence-center/pricing 

All the best,

Alex

[TJ]

Hi Alex,

Thank you for the more detailed explanation on data packets for networks including GCP.  That's essentially my understanding, as far as just a basic outline on the topic.

As far as the reference feedback from the user forums or blog posts, I tried reviewing a bit earlier this week to find them and either no longer have them bookmarked or couldn't easily locate them with a quick search.  When I pull up the first link that you mentioned to the Network Intelligence Center dashboard, for my current project dev test, it results in the following screenshot:

Which seems to be in line with the impression I had, of 99.9% uptime, but this chart is indicating a very slight packet loss of 0.5% or less.  What's interesting is that this is on a 1 hour time scale, and right now I don't have any infrastructure in this project (because I'd already "terraform destroyed" everything, in order to reset and conduct new tests).

It seems relatively insignificant, in light of the progress that has been made to ensure data preservation uptime, especially by GCP.  At the same time, pairing two different virtual private networks together in a peering network, in order to link the different services, or GCP assets, over a longer timeline horizon, was the resulting question I had described before.

Interestingly, after considering your feedback this week, I did some extra research, and found one other GCP customer who tried testing his companies network on both PSA and PSC.  His results suggest what you described, that PSC is newer, better, but also costs more than PSA:

https://www.reddit.com/r/googlecloud/comments/1f6d4cx/psc_vs_psa_in_cloud_sql/

In this above link, he comments the following:

"This is a common issue in the cloud market. For instance, Google was aware of the transitivity issues but has implemented all managed services behind an inaccessible unmanageable network, where peering was your only option. They then introduce a solution, but it requires paying more."

By transitivity issues, was he describing the network peering and/or data  preservation concerns?  It's unclear to me what exactly he's referring to on that point.

Having said, that, through this conversation, I've arrived at the direction to take my project in going forward regarding these available GCP connection options, for which I'm certainly grateful.

Thanks, Tim

[alexmoore]

Hi Tim,

Just on that last question regarding transivity.  They are referring to the typical limitation of peering solutions to allow transit across peering links.

For example, say you have three VPCs:

A is connected to B
B is connected to C

i.e. :    A <---> B <---> C

The constraint is that you can't route from systems in VPC A to systems in VPC C as you cannot 'transit' VPC B, even though it appears from a routing standpoint that this might be possible.

Good luck in your Google Cloud adventures.

All the best,

Alex