On my google VM, Google "automatically migrate an instance" on my account. After the instance was migrated it was shut down. This happened on two of my instances. I can no longer access my site. Can someone help me troubleshoot this? I've included screenshots to help illustrate my concern.
Compute Engine > Operations
After you click on the "automatically migrate an instance
hero-new-production" line item
Thank you for your help.
Have you set Automatic restart On option for your VM instance?
Are you using Local SSD or persistent disk for your VM? Local SSD data does not persist through instance termination. When the instance restarts, it creates a new Local SSD that you must format and mount.
This troubleshooting guide might be helpful
Related
I’m using Jetbrains Gateway to use IntelliJ to work on the code in a remote Linux machine.
I connect via SSH. I connect and work fine initially, the latency is around 150 ms but it keeps disconnecting. I realized it disconnects when I stop coding and spend some time on other things (browser etc.). When I want to re-connect it asks for SSH key passphrase, I need to enter it multiple times and the 'Save Permanently' option won't work.
Is there a setting I can do to keep it connected?
Could this be related to my company's network, in which case again can I increase timeout or retry on fail by some settings?
This is Max from the remote development team at JetBrains.
I'm sorry to hear you are having trouble with Gateway. Please create a ticket here https://youtrack.jetbrains.com/newIssue?project=GTW describing your issue and attaching your logs. This will help us understand whats going on and resolve your issue.
Thanks!
I started using Remote Development feature of IntelliJ connecting to the same remote machine as described here https://www.jetbrains.com/help/idea/remote-development-starting-page.html
It does not disconnect, I can work whole day (tested 12+ hours) without any connection issues.
How can I backup/restore the data on Cumulocity?
Is there any backup feature or service on this platform?
This feature is specially needed when we use the Edge solution and something goes wrong with the edge server i.e. the Hard Disk defects.
Depending on where you are hosting the Cumulocity Edge VM you can export snapshots, e.g. on Hyper-V machines. This snapshot could then be archived/stored anywhere else.
We want to start working with liferay. But the server is too heavy and the developpers computer don't have enought RAM. We want to centralize the server instance.
In other words, we want to build a development server where all developpers can connect and directly develop in their web browser, compile, view the result and push the code to git repository.
I found some good cloud IDE like eclipse CHE and a good maven archetype for liferay projet. So i can build the projet with maven. But now i want to know if it is possible to configure Liferay like every developpers can work without troubling another. And if possible, How ?
The developpers can share the same database and can use different port. Maybe, the server can generate tempory URL like some online cloud editor.
I found this post Liferay With Multiple Server Instances, but i don't think is the best way because he create one server per project. I think is too heavy.
If necessary, We have kubernetes in our IS.
Liferay's tomcat bundle, by default, is configured to take a maximum of 2.5G for the process, but it can run with far less - the default only recently was bumped up, because many people never change the default and then wonder why production systems run out of memory. For 1 concurrent user (the sole developer) on a machine, I guess that the previous default of 1G heap space is enough. Are you saying that that's too much for your developers' machines?
Having many developers on a shared server poses one problem: Yes, you may deploy different code from different machines, but: How about setting a breakpoint? Can you connect with multiple debuggers? If something fails, how do you know whos recent deployment caused the failure?
Sharing a server is an integration technique, not a development technique. If your developers don't have enough memory available for running their own Liferay server next to their IDE, it's a lot cheaper to upgrade their machines than to slow them down when everybody is accessing the same server and they can't properly debug. You pay the memory once, but your waiting developers by the hour.
Is it possible to share one server? Sure it is.
Is it possible to share one server without troubling each other? I doubt.
When you say: You think it's too heavy: What are you basing that assumption on? What does the actual developer machine look like and what keeps you from investing in the extra memory?
It's trivial to share some infrastructure - i.e. have all of them connect to the same database server (and give everyone their own schema). But just the extra effort and setup might require you to pay the developers by the hour as much as you'd otherwise pay for a couple of memory chips.
And yet another option is: Run Liferay on a remote server, but keep 1 instance per developer. This way you don't need the local memory, but can have the memory in the cloud. Calculate if you pay more for remote cloud machines than for local memory - that decision is up to you.
I I just started using Google Colab for a project of mine. I see an button of "CONNECT" on the web page that presents before me two options:
Connect to Hosted Runtime
Connect to Local Runtime
Can anyone explain what the two mean and how it may affect my project? I did not find any useful documentation related to it.
Hosted Runtime runs on a new machine instance in Google Cloud. You don't need to set-up any hardware. But you may need to install a few libraries every time you use it.
Local Runtime runs on your machine at home. You need to install Python, Jupyter, and set-up some forwarding. It is useful if you have a lot of data to process locally, or if you have your own powerful GPU to use.
In most cases, I use Hosted Runtime.
So I have a cloud virtual machine on google compute, does this mean by nature that it is highly available? If the VM is running on a single piece of hardware on GCE, if the piece of hardware breaks then the VM could go down. Is the VM running on some kind of RAID, but for servers? So if one of the machines goes down another machine will pick up and continue running the vm? Thanks.
The machine itself is not highly available. However, Google takes several steps to increase reliability:
Storage is replicated and independent of the physical machine the VM is running on (obviously not for local SSD). This means that even if the physical machine catches on fire, only the "runtime" state is lost but the attached disks are fine.
VMs can live-migrate. This is a setting you can control. If enabled, the VM will be migrated to a different physical machine on maintenance events. Live-migration can lead to brief performance degradation while memory etc. is synced to the other host but the machine is not shut down / restarted.
Even when the physical host suddenly dies, you can set your instance to restart automatically on a new machine. If you plan to use this mode, make sure your instance is able to cleanly boot to serving state without manual intervention.
If you need high availability, the best approach is to spread your instances among zones of the same region and using a network or HTTP(S) loadbalancer. These will automatically stop sending traffic to a machine in case it becomes unhealthy. Also see this short youtube video on Google's network architecture for more info.
For high availability of your application data, there are highly available options like Datastore for database-like usage and Cloud Storage for file-oriented data. Keep in mind that Cloud SQL also runs on a single instance/physical machine which means that you have to setup slaves/replicas to get high availability. However, you can also do that with your favorite DB system on plain Compute Engine instances if you are willing to maintain them yourself.