I have an instance which was created in Australia region, the zone is australia-southeast1-a. However, I find that the External IP is still in US:
Had tried creating another instance in another region (asia), and logined using ssh, haven't noticed any significant difference in latency, the responses are both not very fast.
My question is, have I correctly setup the region to Australia? Or is there any configuration that I have missed?
Your setup on the VM and its configuration are perfectly fine. You have your hardware physically located in the Australian region. Your concern over IP’s location is just a mere confusion. This had happened to most of the customers.
Most of the external Geo IP services are depending upon the SWIP database. And for this reason, most of the Google’s IPs are SWIP’ed to the Mountain View, CA. Because of this, even for a VM which is created outside (in your case Australian Region) the US shows its IP location as in the US.
Furthermore, you can also go through this Google discussion thread which will give you more comments on this matter.
Related
I'm attempting to assign a domain name to my Google Cloud VM external IP. I was following some walkthroughs and getting a bit confused. I set up apache with a simple "Hello" message when you visit my external IP. The walkthroughs I'm following are providing steps to reserve a new static external IP and creating a DNS zone.
Could someone provide clarification on why I would need to secure a new static external IP address when it appears I already have one assigned?
As discussed by #Ferregina Pelona in the comment section. The public IP that your VM already has is an ephimeral one which means that if the VM is stopped or restarted, there is a possibility this public IP changes. The problem will be that if it changes, your DNS will continue pointing to the old one which means your site will be not accesible until you update the DNS with the new IP. Reserving the public IP will warranty your VM always has the same IP.
Also, added by #DazWilkin. it should be more explicit in the documentation but I assume (!) it's an ephemeral IP. I submitted doc feedback for this.
I assume you're following a guide like [1]
The tutorial demonstrates the following steps when assigning a domain to a VM which would act as a server:
-Register a domain name using Google Domains or Cloud Domains
-Create a virtual machine (VM) instance
-Run a basic Apache web server
-Set up your domain using Cloud DNS
-Update name servers
-Verify your setup
However, there is a very important note that I believe clarifies completely the scenario you faced and the questions regarding this which states:
Note:By default, the VM instance that you create receives an ephemeral external IP address. Ephemeral external IP addresses are lost whenever the VM instance shuts down or reboots for any reason (for example, maintenance). To avoid shutdowns and reboots, use a static external IP address for web hosting. For instructions about how to reserve a static external IP address, see Reserving a static external IP address.
My suggestion would be that you try always to find an official docummentation according to the configuration/products you're expecting to use so as shown in this section, these are the advices that could avoid you yo fall into errors while moving forward. I hops this info make sense for you...
Cheers,
TLDR: I could use some advice on how to setup Redis for production use on GPC, it just switched IP addresses on us randomly, and there is nothing in the documentation about that / I have no idea how to build a stable solution with that possibility.
Background:
We've been using google cloud for a few years and had a stable Redis Memorystore instance on the 'Standard' Tier.
In the past few days, our web servers started slowly crashing every so often. After investigating, something was locking up when connecting to celery / Redis, and we found that all our config files had 10.0.0.3 as the Redis instance, and the IP address for the server was listed as 10.0.0.4. This hasn't changed ever, and our configs are in git so we're sure they were unchanged.
Since Celery won't boot up with a bad connection we know it was correct on Tuesday when we pushed up new code. It seems like the server failed over and somehow issued an IP address change on us. As evidence,
Our graphical usage bizarrely change color at a specific point
Which matches our error logs "[2020-06-16 03:09:21,873: ERROR/MainProcess] Error in timer: ReadOnlyError("You can't write against a read-only slave.",)"
All the documentation we have found says the IP address would stay the same, but given that didn't happen, I'm hoping for some feedback on how one would work around a non-static IP in this case on GPC
Memorystore does not support static IP address. Some scenarios where IP address change can occur are restarts or when connection modes are changed.
From review of the Memorystore for Redis networking page, when using direct access connection via IP address your project will set up a VPC network peering connection with Google's internal project, where the instance is managed. This will create an allocated IP range for Memorystore to use for the instances, this can either be provided by you or picked from the available space (will be a /29 block by default).
On the other hand, Memorystore for Redis exposes the uptime as a metric that is available through Cloud Monitoring (formally Stackdriver). This can be used as a health check for the instance as you will be able to determine if there has been a restart or points of unavailability.
Following the point above, you are able to set up an alert on the uptime metric directly in Cloud Monitoring. Unfortunately there is nothing specific to IP address changes though.
We deployed the Gitlab server on a Compute Engine instance with an attached static external IP address. From time to time, the server is unavailable to us upon requests from Russia. When using the "tracert" command, packets do not go beyond the address 209.85.243.152 (Google LLC). However, the Gitlab site is fully accessible upon requests from other regions at any time.
The problem was preinstalled sshguard, which mistakenly added my IP to the list of blocked ones.
There is a solution instruction in this answer.
If I set up Cloud NAT, and attach it to a network, I am charged about $0.050 per hour. This is fair since I don't have to set up my own NAT instance and I don't have to manage it myself.
Furthermore:
When reserving a static IP address on GCP, I am charged at a rate of about $0.010 per hour as long as I don't attach the IP address to an instance or a load balancer.
I understand that this is done to dissuade users from creating unused IP addresses.
However:
If I create a Regional IP address and instruct Cloud NAT to use that as its external IP address, the IP address is still marked as "unused" in the Cloud Console (In use by: None in the Web UI, and RESERVED using the gcloud command).
This leads to two things:
Confusion: It is not immediately obvious that the reserved IP address is in fact in use, and someone might try to delete it.
An unused IP address is charged, which is fair if it is indeed unused, but I would argue that it is in fact not unused, and google is running an "invisible instance" for me (even though it's just a network service feature in Andromeda, and probably does not involve a single running instance - at least according to the docs)
If anyone knows if this is a feature or a bug, I would be very thankful (and I would also be thankful if I could save $0.010 per hour :D)
Update
From the billing console I can deduce that the static IP address is not being charged for (when attached to Cloud NAT), even though it is marked as "unused".
The question is now if the bug is with the Web UI/gcloud or the billing system.
I purchased a GCP VM instance in asia-southeast1 and reserved an external IP in the same region for this.
The instance and IP information that is shown in GCP console seems to be okay but when I deploy my website into it, the response is really slow.
My static IP
VM instance
So I lookup my IP and the tool show my IP is from US
IP lookup result
I am not sure what wrong with my IP or instance, I am new in GCP please help. Thank you.
If I search the whois data for external IP address of a Virtual Machines in GCP zone asia-southeast1 I can see that the address points to Google's headquarters in Mountain View, CA. The whois data has no indication of where in the world the actual hardware is located...
Many external Geo IP services depend on a SWIP database. Most of Google IP's are SWIP'ed to be Mountain View, CA. That means a VM living in a datacenter outside of the U.S. might show a linked U.S. IP address, as in your case. I suspect that most of Google's addresses will be originally US allocated.
The external IPs that are assigned to Google Cloud customer's projects are from an address block(s) that belongs to Google and is Geolocated there:
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=35.193.232.48?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 35.192.0.0 - 35.207.255.255
CIDR: 35.192.0.0/12
NetName: GOOGLE-CLOUD
NetHandle: NET-35-192-0-0-1
Parent: NET35 (NET-35-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google LLC (GOOGL-2)
RegDate: 2017-03-21
Updated: 2018-01-24
Comment: *** The IP addresses under this Org-ID are in use by Google Cloud customers ***
Comment:
Comment: Direct all copyright and legal complaints to
Comment: https://support.google.com/legal/go/report
Comment:
Comment: Direct all spam and abuse complaints to
Comment: https://support.google.com/code/go/gce_abuse_report
Comment:
Comment: For fastest response, use the relevant forms above.
Comment:
Comment: Complaints can also be sent to the GC Abuse desk
Comment: (google-cloud-compliance#google.com)
Comment: but may have longer turnaround times.
Ref: https://whois.arin.net/rest/net/NET-35-192-0-0-1
OrgName: Google LLC
OrgId: GOOGL-2
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: US
RegDate: 2006-09-29
Updated: 2017-12-21
(...)
That does not mean that your VM's address is responding from Mountain View, if your instance is in Asia. In your case, your instance in asia-southeast1 and is physically located in Singapore.
You can also choose the region for your static external IP, just go to VPC Network -> External IP addresses -> Reserve static address and you can choose the region where the external IP will be located. It will still be displayed as from the US by the whois databases, because it belongs to the Google bloc, but the entry point will be routed in Singapore, that should improve your latency.
Thank guys for clarification about the IP, it is not related to my issue. I got confused with GeoIP at first.
After all, I found out that the slow response is caused by 2 things below:
Database region: My Google Cloud Sql (mysql) region is in Australia because GCP Cloud Database has no server in SEA. I tried to change database region to asia-east (exactly is in Taiwan) and got doubly faster response.
Connection method: GCP provide 2 ways to connect to its cloud sql: Database External IP (with IP whitelist config) and via Cloud SQL Proxy that both have network latency. I think GCP should support database communication inside a VPC. I am not sure why GCP does not support this way currently.
The response of my website is now better but much slower as compared with the same one I deployed into AWS. In AWS the communication between my App and database is done inside a VPC, no public IP exposed and no network latency. Moreover, AWS database have server in SEA that why AWS is much faster in my case
Response time: GCP vs AWS